Move to... file action should delete the source when moving to external drive

[BrianDoh]

Hello,

if I perform the "Move to..." file action on a file on my internal Mac SSD (on Desktop for example) and try to move it to an external drive Alfred is coping the file instead of moving it.

 

I discussed the issue here:

https://www.alfredforum.com/topic/11442-move-file-action-is-always-copying-instead-of-moving/

 

And the only other mention of this problem I could find is from 2013/2014:

https://www.alfredforum.com/topic/1331-move-file-not-always-working/

 

As I understand, Alfred is using the Finder to move files and the default Finder function is copy if the destination is on an other drive/partition as the source file. This is an explanation but still the action is named "Move to..." not "Sometimes move sometimes copy to..." so I think this is a bug/behaviour that should be fixed.

 

 

What you were doing when the issue happened

Trying to move a file from Desktop to external drive

 

Whether you were able to replicate it a second time by performing the same action

Every single time

 

Include any screenshots that might help us

-

 

Include the Alfred version & build number you are using

Alfred v3.6.1 [910] with Powerpack

 

Include your OS X version

Macbook Air with Sierra 10.12.6 and Macbook Pro with High Sierra 10.13.3

 

Edited April 22, 2018 by BrianDoh

[vitor]

I’ve edited the title, since “failing” means something different. As stated in the other posts, this is working as designed. The question here is if the designed way makes sense or not.

 

For that reason, I also think this should be a Feature Request instead of a Bug Report, but since that’s debatable it makes sense for @Andrew to be the one to make that call.

 

For what it’s worth, I agree that a move should always mean a move. And it’s not like the Finder is adamant about copying when it’s for external drives — if we press ⌘ when dropping the file, it’ll indeed move instead of copying.

[deanishe]

1 hour ago, vitor said:

I also think this should be a Feature Request instead of a Bug Report

 

FWIW, I came down on the side of bug report, not feature request, because the labelling is confusing.

 

I think asking Finder to perform the copy/move is useful, as that means you can Undo the operation in Finder.

 

I don't think Alfred's Move To… action's following Finder's default behaviour is so good, however, because as you note, a key feature of Finder's behaviour is that it's easy to override its default action with modifier keys.

[Andrew]

This is something I've known about for quite some time, and has been discussed in various forms a few times.

 

The reason I've left this as default AppleScript behaviour of copy when external drive (at least for now) is because this forms a safety net should something happen.

 

When moving on the same disk, the reference is simply updated, and no file is actually physically moved and no file data is changed. When moving to an external drive, the physical file is written to the new drive and the new drive will report back that this is "successful", but there is a chance that the file has been written to some bad sectors and by automatically deleting this file from its origin, the file is now lost.

 

This is essentially why Finder's default behaviour changes to copy (unless you force it with cmd), and AppleScript changes the move command to a copy command automatically.

 

I'm still on the fence as to what to do with Alfred, but I do agree with Dean that a move should mean a move.

 

Cheers,

Andrew

[deanishe]

52 minutes ago, Andrew said:

there is a chance that the file has been written to some bad sectors

 

That's HFS+ being HFS+, though, isn't it? I mean, I can't avoid that risk unless I re-read the destination file and compare it to the original.

 

Finder's behaviour is, imo, mostly a cop-out so Apple can take a "well, you forced the move!" position when the real problem is that HFS+ is a terrible filesystem. (Obviously, that doesn't apply to Alfred: you didn't write the filesystem, AFAIK).

 

Perhaps Alfred could offer a "safe" move, whereby it copies the file and then trashes the original? That's essentially Alfred's current behaviour, except I have to do the trashing manually.

Edited April 23, 2018 by deanishe

[BrianDoh]

This is a good reason and I can fully understand why you hesitate. If someone loses a file when moving it with Alfred the user is going to blame Alfred not the crappy filesystem.
But on the other side I think it is bad user experience design if some essential command like this is not working as expected and there is no information why.

 

Maybe you could implement an option in the File Search options panel or the Advanced preferences tab to switch the move behaviour to what the user expects it to be (move is moving the file every time)? There you could leave some explanation about this behaviour too.