Major bug: FCMove sometimes delete files when it should move

[cstern]

Here's the setup:

Left folder:

/Volumes/My Book/Test

Test folder contains files file2, file2,...etc

If I select all files and use "Move folder to..." and specify /Volumes/My Book/Test as target, the files should not be moved (the source and the target are the same). But what happens is that FC starts the process and fails. Unfortunately in the process the source files are deleted!

I just almost lost 5000 files on that account before I realized my mistake. (backup is a good thing...)

If you use the Move to right command with the same folder on both sides it is not possible (greyed out), which is logical.

[cstern]

I just checked in BC3 for windows. Same thing happens.

Although this may be a rare case, the consequences can be disastrous for the person doing this.

I guess what happens behind the scenes is that the move is actually a copy + delete sequence: First the source is copied to the target. Then when the copy is completed successfully the source is deleted. This works fine when the source and targets are different. But when they are the same the file is deleted without warning.

I suggest a check to see if the source and target directories are the same when doing a "Move to.." command.

[edgy]

Yes, that is a nasty bug.

[Aaron]

Thanks for the report. I'll open a bug tracker to investigate this.

[cstern]

not fixed in 971

[cstern]

not fixed in 17036

[Tim]

We're working on a fix for this in an upcoming release, at least for the case where the source and destination specs are identical. I don't see how we can avoid the problem if there's an alias involved, such as different drive mappings to the same location.

[cstern]

I don't know about these things, but is there a universal naming for a given location which "sees through" mappings, so that the OS could provide the actual path? On a local mac (unix) I guess the attributes should reveal if a directory is a proper directory or a link/alias.

On a windows client machine E:\ and F:\ could both point to a remote path //readynas/public/

If on the remote directory //readynas/public is linked (Unix-wise) to another path on the same host, e.g. //readynas/files/, then a mapping on the windows client to E:\ and F:\ for each of these, would leave us in the mess anyway, since there would not be an easy way to tell that the two directories in fact are the same. In that case, perhaps, an "clumsy" solution could be to probe the target and source with an empty test file to see if it shows up both places - should only be necessary on remote hosts, I guess(?). Not terribly elegant, but would save some griefs...

[Aaron]

I'm unsure, but I'll add these notes to our tracker entry for our developers to research.

[cstern]

just for the record. Not fixed in 17440. (I know it is on the list, so you don't have to reply)

[Zoë]

This will be fixed in the next beta release. Not a new bug though; it's existed on Windows and Linux since "Move to Folder" was introduced in v3.