"Move file" copies file instead

Questions & Suggestions
1

Sometimes “move files” copies files for me instead. I can’t reproduce it on command, but it happens frequently. Does this happen to anyone else?

2

I think “Move Files” copies the files, if the source and destination aren’t the same drive.

3

Thanks, Dan. They are the same drive.

1 Like
4

Anyone else got an idea on this one? It happens relatively consistently with a few specific folders. I think I could reproduce it if I tried a few times.

5

What happens when you manually drag the files? Does the same thing happen? Meaning, does it default to copying instead of moving?

6

Which folders?

If it’s a read-only folder and you try to “move” something out it will most likely get copied instead.

If – in the Finder – you drag something out of the /Applications folder you will get an Alias instead.

1 Like
7

Hey Jack,

You’re going to have to produce a specific use-case for us to test.

Clearly this issue isn’t happening often to everyone, or there would be more interest in the thread.

One thought – could the item that gets copied (instead of moved) be locked in the Finder?

-Chris

8

Thanks for the tip, @DanThomas Now I’m having trouble reproducing it reliably, but I’ll test that next.

@Tom Thanks, no, it’s a user-created folder with photos in it.

@ccstone Good point, I’ll focus on trying to reproduce. Thanks for the advice. No, the files aren’t locked.

10

Assuming that the problem occurs with every file in that folder, check the attributes of the folder:

####A. Paste this into the Terminal:

ls -ldeO

Copy only the text, without any linefeed, then add a Space at the end and drag the folder into the Terminal. It should look now like this (example):

ls -ldeO /Users/tom/_Tmp/testfolder

(The /Users/tom/_Tmp/testfolder part is the path of the folder in question.)

####B. Then press Return (in the Terminal).

You should get something like this (example):

drwxr-xr-x+ 3 tom  staff  uchg 102 Jan 12 16:36 /Users/tom/_Tmp/testfolder
 0: group:everyone deny delete_child

####C. Copy the output and post it here.
‌

Key (for the example above):

  • drwxr-xr-x: Permissions (here: 755)
  • tom staff: Owner and Group
  • uchg: System flag (here: user immutable)
  • 0: group:everyone deny delete_child: ACL entry (here: no file deletion allowed)
11

@Tom Thank you

drwxr-xr-x@ 2305 jack  staff  - 78370 Jan 16 15:51 /Users/jack/Dropbox (Personal)/Design Inspiration

It didn’t return any additional text.

12

First the most important thing:

  • Have you already tried to manually move a file out of that folder? (In the Finder.)
  • If manually moving works without problems, post your macro here.

Assuming jack is you, the folder seems to be OK, in terms of permissions and ACL. The only strange thing are the unescaped Spaces in the folder path. But maybe the backslashes were lost during pasting. The folder has extended attributes, but this shouldn’t be important.

However, since the folder seems to be in your Dropbox folder, it is not a completely regular folder. It is to some degree managed by Dropbox, but I don’t know if Dropbox has the ability to apply some additional access control.
I tested it with some of my Dropbox folders and I don’t have any issues.

You were speaking about “a few specific folders” where the problem occurs. Are those folders all Dropbox folders?

If manually moving a file in the Finder doesn’t work either, you may try this:

  • Quit the Dropbox application and try it again.
  • Unlink Dropbox from the folder and then relink it again. (Make sure to have a backup of the folder contents.)
  • Dropbox is up to date? (I remember, there have been issues with Dropbox or other sync services after introduction of Sierra. I had to download the latest installer because Dropbox’s auto-update didn’t work.)
13

@Tom thanks for your notes.

Have you already tried to manually move a file out of that folder? (In the Finder.)

Yes, and that seems to work fine. Can't reproduce the issue there.

If manually moving works without problems, post your macro here.

Here you go: Move to Inspiration Folder.kmmacros (20.2 KB)

You were speaking about “a few specific folders” where the problem occurs. Are those folders all Dropbox folders?

Yes, they are all in Dropbox! Weird.

I can reproduce the problem ~50% of the time (right now) when Dropbox is on and 0% of the time when Dropbox is off. I don't need to move the folder to make the problem happen.

Here's the weird thing. I was just testing with another folder in Dropbox:

/Users/jack/Dropbox (Personal)/Wallpaper/

I have an identical macro that uses that path above as the MoveLocation variable. When I run this macro, KM consistently tells me it can't move the file because something already exists in that location.

14

Here you go: Move to Inspiration Folder.kmmacros (20.2 KB)

Your macro works flawlessly for me. That is, I cannot reproduce the error.

Yes, they are all in Dropbox! Weird.

I can reproduce the problem ~50% of the time (right now) when Dropbox is on and 0% of the time when Dropbox is off.

OK, this seems to point clearly towards Dropbox. But I don’t understand why it isn’t happening when you do the same in the Finder (without KM macro). However, I don’t know the underlying code of KM’s move action. Maybe @peternlewis has an idea.

Especially if you are on Sierra, have you tried to

  • unlink/relink Dropbox from the folder, as proposed above? (maybe throw in an OS restart in-between)
  • update Dropbox by using a freshly downloaded installer?

I have an identical macro that uses that path above as the MoveLocation variable. When I run this macro, KM consistently tells me it can't move the file because something already exists in that location.

When KM tells you that, it is usually true. I’m assuming you mean the message “File action failed because destination already exists…”

The 2nd part of that message tells you the exact path that is responsible for the error. Check that and check also the exact path composition in your macro. Sometimes an accidentally wrong path composition in the move action can lead to that result. (For example a missing last path component, so that KM tries to copy always the parent folder.)

But this is not the case with the macro you have posted, as said, it works fine here. And I get “File action failed because destination already exists…” only when the file indeed exists at the destination. So, this is probably a separate problem.

Are you using the current KM version? (I’m asking because IIRC there was a change with the path parameter of the Move action, but I don’t remember in which version.)

15

I wonder if DropBox is trying to do some behind-the-scenes magic to integrate with Finder, and perhaps this doesn’t work as well outside of Finder?

16

Yes, something like that; see the famous Dropbox hacks (and discussion). I guess there was also a relation between these hacks and the Sierra/DB problems. But I thought it had been repaired. (There have been a couple of DB updates since Sierra introduction.)

1 Like
17

Could be.

Keyboard Maestro uses the very simple line of code:

[fileManager moveItemAtPath:source toPath:destination error:&error]

So there really is not a lot of scope for it to be adjusted.

The Apple documentation says:

When moving items, the current process must have permission to read the item at srcPath and write the parent directory of dstPath. If the item at srcPath is a directory, this method moves the directory and all of its contents, including any hidden files. If an item with the same name already exists at dstPath, this method stops the move attempt and returns an appropriate error. If the last component of srcPath is a symbolic link, only the link is moved to the new path; the item pointed to by the link remains at its current location.

If the source and destination of the move operation are not on the same volume, this method copies the item first and then removes it from its current location.

It is certainly possible that Dropbox is interfering with the action in some way, but there is not a lot Keyboard Maestro can do differently as you can see from the simple API used.

You could try using a shell script along the lines of:

mv "$KMVAR_Source" "$KMVAR_Destination"

That would certainly have different semantics (for example it will overwrite a destination file!) and so might behave better in your usage case if there is some sort of bug or interaction between Dropbox and the system.

18

@DanThomas @peternlewis @Tom

Thanks all for your thoughtful suggestions. I’m ready to chalk this up to Dropbox.

1 Like
19

Perhaps it is, but I've been using DropBox extensively for years now, and I have never experienced this, or any other file-related issue, with DropBox.

Of course, I'm still running macOS 10.11.4.

20

I’m running Sierra and I also don’t have any file-related issues. But, interestingly, Dropbox does not behave well here: When Dropbox syncing is enabled for a while, the Finder becomes increasingly sluggish. For example, when I click the Finder icon in the Dock it can take 20 seconds or so until the Finder windows come to front.

OK, I can not say with 100% certainty that it is Dropbox. I still haven’t systematically excluded all other background processes. But, once I pause Dropbox syncing the Finder slowly and reliably gets back to normal behavior.

But we don’t know if the OP is on Sierra or on a previous system.

21

You may want to post this in the DropBox forum and/or submit a support ticket to DropBox. I would think if this is a Sierra bug then lots of users would be experiencing it.