GNOME Bugzilla – Bug 312707
moving a file or folder onto itself destroys it
Last modified: 2005-08-11 05:01:26 UTC
Please describe the problem: If you end up in the same directory in two windows (via two different paths) in nautilus, and try to move files / folders from one window to the other, the files / folders will be deleted. Steps to reproduce: 1. mkdir -p parent1/folder 2. ln -s parent1 parent2 3. nautilus parent1 parent2 4. drag 'folder' across 5. confirm replace Actual results: 'folder' deleted Expected results: 'folder' stays put. An error message saying why would be nice. Does this happen every time? yes Other information:
I can reproduce it.
Created attachment 50303 [details] [review] patch0.3: workaround, gnome_vfs_file_info_matches handle_name_conflicts detects that a move is_move_to_self when the source and target are gnome_vfs_uri_equal. That check misses the testcase because it doesn't compare realpaths. This patch makes a move be considered to_self also when source gnome_vfs_file_info_matches target. Unfortunately that means that if the source and target of a move are identical but separate hardlinks, the source won't be removed. That's a safe failure, though. With this patch, nautilus removes the unmoved item from the source view as if it had been moved, but it appears again at refresh. A proper fix would seem to involve realpath (for all methods?) or renaming/moving the target out of the way, or somesuch. The last hunk is an unrelated random leak fix in gnome_vfs_xfer_uri_internal. First gnome patch -- keep your eyes open :)
Created attachment 50324 [details] [review] patch1: leafname + parent fileinfo uh, perhaps not that complicated, after sleeping on it ;) to avoid move of a directory entry onto itself that kills it in the pre-cleanup phase: - fastpath with existing uri_equals check; that failing - check directory entry name match, and - check directory entry namespace match (same parent fileinfo) When at least one or both of the parents is a symlink, non-stat-like bits in the fileinfo, having to do with the link, are clobbered before matching, since we care about the target, not how we got there. Works for the multiple hardlink case too, since they fail the same-namespace check.
...and fails in various ways on various methods, since I can't really uniquely identify fs objects on this level, now can I. back to the drawing board. http://mail.gnome.org/archives/gnome-vfs-list/2005-August/msg00005.html
I knew I have seen that somewhere in bugzilla before. *** This bug has been marked as a duplicate of 311591 ***