I have a network drive, formatted MacOS Extended (Journaled). That drive contains my archive of customer projects.
When I start a new project for an existing customer, my workflow is to move the customer’s folder from the network drive to my laptop’s internal SSD. That way I have all the reference material, etc. on my laptop - even when I’m away from my server. And the reverse when I conclude the project.
I use “move” instead of “copy” because sometimes files get renamed, deleted, etc., and I don’t want to have to hassle with merging versions.
Now here’s the issue.
Not-infrequently, when moving via Finder, Forklift, etc., it will tell me that a file (usually a couple levels deep in the moving folder) already exists and prompt me to do something about it. But it can’t already exist, because the root folder didn’t exist until I started the move.
This stops the process entirely, and it’s insanely annoying. I frequently do this at night, over a lunch break, etc., and come back to the process not being finished - sometimes barely even started.
I can use rsync, but it won’t clean up the remote folder structure. And honestly, it’s borderline ridiculous that I should have to use a command line tool because the GUI can’t figure out how to move a folder properly.
Is there something I’m missing here? Or is there a better tool that’s rock-solid for moving a folder like this?
Does it happen if you use “copy” instead of “move”?
Is the target folder stored in iCloud Drive per chance? Perhaps there is some “file storage optimization” going on that fails.
Does it happen if you use Unix terminal commands? Perhaps this is something related to how the Finder performs file operations over network drives (and I would assume Forklift it using the same Apple frameworks the Finder is using).
First, it strikes me as noteworthy that you did not report the same issue when doing the reverse; moving files from the internal drive to the external archive. If, in fact, the problem is only encountered when moving the one way, then you need to do more debugging.
The first thing I would do is confirm if the same problem presents itself if you do a copy instead of a move. If not, then we have established that this is unique to move only.
Then I would confirm if the problem exists with command line move (and copy, if that failed above). If not, then this may be a problem with Apple’s implementation of move. However, if the problem persists here as well, then that suggests maybe dropbox is the issue.
If everything above fails, then I would try moving (and copying) to a location on the internal drive but outside of dropbox. That should finally confirm if the problem is with dropbox or not.
If the problem still persists, then what method(s) have you tried that do work? I get the sense from your report that you eventually do get all of the files moved over, but without more information, its difficult to know what could be causing the issue. For example, does the error only occur with a certain file type or with files over a certain size? Are there any other patterns that could help narrow it down?
I get nervous with “move” because if something goes wrong, then where is everything?
I’d make sure the folder doesn’t exist on the internal drive (deleting it first if necessary), do the copy to the internal (which gives you a temporary backup on the external!), do the work, delete the now backup on the external, copy the folder back to the external, and then if everything works out alright, delete the internal.
Note that I’ve used Chronosync in the past to do this, but manually copying or using rsync (shudder! too easy to goof up) work as well.
Given that copy works, I am with @tomalmy. Use copy. For that matter, you can leave the archive there until the project is complete and you are ready to archive it again. Just delete the old archive first, then move the updated files to the archive.
I understand not wanting to go to the command line, but why not create a reusable script? There any many ways to call a script outside of the commandline.
You could try using a utility like Dropover, which allows you to place a folder or file in a small window from which you can move it to its destination.
I’d remove Dropbox as a factor first. Are there any issues when you copy the files to somewhere else locally?
This is a shot in the dark – I’m currently not using Dropbox – but there could perhaps be an issue with file/folder naming restrictions or path lengths within the Dropbox folder. I know Dropbox has fewer restrictions here than OneDrive (which I’m using), but some characters are not allowed in OneDrive, and their app will offer to rename these, with Microsoft even recently announcing that some files may be renamed automatically on upload (!). It is not inconceivable that Dropbox may be doing something similar if some files or paths conflict with their naming restrictions, confusing Finder.
I don’t know the solution for the problem you are having, but I handle client folders slightly differently.
I include the date of last interaction in the folder name “2024-12-30 webwalrus” for example.
When I do additional work for a client, I duplicate the folder and then rename it with the current date. Then I copy the folder to my local system or laptop.
This gives me a working copy, plus an extra copy on the server as a further backup.
When project is completed, I rename again with the current date and copy to the server. Then I delete the intermediate folder copy on the server.
As others stated, I’m just too nervous to ever use move and prefer to copy and then delete, as needed, duplicate folders/data.
I don’t have many other folders that have 1000+ files in them that I move around. I suspect it has more to do with the file quantity than anything else, but I’m not sure why.
I guarantee I’m not breaking the limit. Especially since letting the move “overwrite existing files” or whatever allows the move to finish up, which wouldn’t be true if it was a character length issue. The issue is that (a) the popup delays the process since I’m frequently not at the computer babysitting it, and (b) it shouldn’t happen in the first place since the folder is empty.
Although based on your comment that copy doesn’t work it won’t solve your problem. But I agree it is a better process as it will ensure you have the original files should a catastrophic failure occur.
So back to troubleshooting, does it always occur when moving large client folders (you noted some ‘randomness’ above)?
It’s definitely not all the time, but the larger the folder, the greater likelihood.
I’m wondering if it’s just some instability with the network copying itself. Last night I tried moving a folder to my Documents folder (i.e. “not Dropbox”) using Finder, and this morning there’s no progress window, the move looks to be done, but when I tried to put the folder in a subfolder I get a message that the folder “can’t be moved right now because it’s being used by another task, such as moving or copying an item or emptying the Trash. Try again when the current task is complete.”
“lsof -p” doesn’t show anything related to the move in the Finder process, so there’s no reason to believe it’s not done.
At this point I’m writing some rsync scripts. I’m making a “Check Out” folder on the remote server, and a “Check In” folder on the local one. I run a script, and anything in “Check Out” comes to my laptop, and anything in “Check In” goes from my laptop to the server via rsync. I can manually clean up once I see that they’re done.
And I incorrectly interpreted that “yup” as ‘yup, copy works’ instead of ‘yup, the same problem presents itself.’ Opps. Sorry for the confusion.
In any event, based on your feedback, I think your current conclusion is reasonable. Perhaps Apple’s move/copy implementation doesn’t always work reliably over the network. A script (or 2) to move the files seems like a reasonable resolution.
