Page 1 of 1

LB5: Copy/Move - move only copies across drives

Posted: Fri Dec 12, 2008 12:45 am
by beejay
Is this me doing something silly or another bug?

It seems that doing file operations with Launchbar - "Copy" works fine, but "Move" only does a copy (ie, the source file is not deleted after a move operation) when trying to move a file from my system drive to an external drive. I get the same results using the menu copy/move options, or by using the modifier keys command/option-RETURN to perform the action.

Pick up a file in the finder TAB select destination folder RETURN select "move" from the menu = file is copied, not moved, to the destination, and the source file stays where it was.

Note - if the source file and destination location are on the same drive, (whether the system drive or an external drive) move works as expected (the source file is deleted after the move). However, if the source file is on the system drive and the destination is on one of my externally mounted drives, it only does a copy... It seems that if the file is going to a different volume, no move is done. This strikes me as undesirable behaviour...

Thoughts?

Posted: Fri Dec 12, 2008 1:55 pm
by norbert
This appears to be a bug in Mac OS X. We use a system call to perform the move operation which is documented to move across volume boundaries as well. But apparently it doesn't.

We'll have to implement a workaround to remove the source item manually once it has been successfully arrived at the destination.

Re: LB5: Copy/Move - move only copies across drives

Posted: Fri Dec 12, 2008 8:32 pm
by sjk
beejay wrote:if the source file and destination location are on the same drive, (whether the system drive or an external drive) move works as expected (the source file is deleted after the move).

Actually a move on the same filesystem is simply a rename. You can prove it to yourself by moving a huge file and notice it happens nearly instantly. There's no need to copy its content, like when copying/moving across filesystems (which takes increasingly longer as the size increases).

norbert wrote:We use a system call to perform the move operation which is documented to move across volume boundaries as well.

Which call?

Posted: Fri Dec 12, 2008 9:23 pm
by norbert
sjk wrote:Which call?

FSPathMoveObjectAsync()

The documentation states:
If the destination directory is not on the same volume as the source object, the source object is copied and then deleted.

Posted: Fri Dec 12, 2008 10:47 pm
by sjk
Thanks, Norbert. Being a Unix geek seeing system made me think you meant a BSD System Call. :)

I'm curious if FSPathMoveObjectSync behaves as documented with regards to cross-volume moves, though I'm not enough of a coder to test it. Maybe that's usable in a FSPathMoveObjectAsync workaround but I'm just naively guessing.

Posted: Fri Dec 12, 2008 10:59 pm
by norbert
sjk wrote:I'm curious if FSPathMoveObjectSync behaves as documented with regards to cross-volume moves, though I'm not enough of a coder to test it. Maybe that's usable in a FSPathMoveObjectAsync workaround but I'm just naively guessing.

Using FSPathMoveObjectSync would block until the file operation has completed, whereas FSPathMoveObjectAsync performs the file operation in background. But we have already implemented the aforementioned workaround of deleting the source object(s) manually, if necessary. So this issue will be addressed in the next beta.

Posted: Fri Dec 12, 2008 11:05 pm
by sjk
Yep, I was aware it would block but not sure whether it was possible to create/use a new thread for it in that context, basically simulating FSPathMoveObjectAsync. Better I just leave any workarounds to your expertise and stop speculating about 'em. :)

Thanks for keeping us informed.

Posted: Fri Dec 12, 2008 11:49 pm
by ludwigschubert
… although, when you have to start talking about threading issues for a simple file moving command, it makes you wonder about Apple's API, doesn't it?

Glad that Norbert can do it better himself, :D
Ludwig

Posted: Sat Dec 13, 2008 12:32 am
by sjk
Kind of puzzling why there still isn't an atomic move() Unix/POSIX/BSD/Linux (whatever) syscall for FSPathMoveObjectAsync (et al) to exploit. Seems related to one of those stubborn Unix legacies you can love to hate, i.e. rename() basically unchanged since single-drive/volume Unix systems were the norm when the "must reside on the same file system" limitation was relatively insignificant.

Posted: Sat Dec 13, 2008 12:38 am
by norbert
Suggested Reading: Apple File Systems :wink:

Posted: Sat Dec 13, 2008 3:04 am
by sjk
Interesting, ignoring some of the typical flamboyant Radsoft/Rixstep flamboyance.

Posted: Mon Dec 15, 2008 11:46 pm
by beejay
Confirmed fixed in beta 2. Thanks!