After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 99346 - cutting a folder whose parent has the same name, and pasting it inside the parent's parent, causes both it and its parent to be deleted
cutting a folder whose parent has the same name, and pasting it inside the pa...
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Cut Copy Paste Undo
unspecified
Other other
: High critical
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-11-23 09:06 UTC by Ittai Balaban
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.0



Description Ittai Balaban 2002-11-23 09:05:31 UTC
Package: nautilus
Severity: normal
Version: 2.0.6
Synopsis: cutting a folder whose parent has the same name, and pasting it inside the parent's parent, causes both it and its parent to be deleted
Bugzilla-Product: nautilus
Bugzilla-Component: Cut Copy Paste Undo

Description:
Description of Problem:
If folder "x" contains folder "y", and folder "y" also contains a folder
named "y", then:

Steps to reproduce the problem:
1. Cut the nested folder "y"
2. Go to folder "x"
3. Try to paste

Actual Results:
Naturally nautilus kind of gets lost: It asks if you want to replace
"y". When you click "yes" it says that a file cannot be found. Click
skip or stop, and now both "y"'s are gone.

Expected Results:
I guess this action should be checked for as a special case and either
disabled, or carried out using temporary renaming or something.

How often does this happen?


Additional Information:




------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-11-23 04:05 -------

Reassigning to the default owner of the component, nautilus-maint@bugzilla.gnome.org.

Comment 1 David Kennedy 2002-11-23 16:01:17 UTC
Verified in both 2.0 and 2.1 - this could be a serious problem since
the folders are deleted with no way of restoring them. Setting
severity to major.
Comment 2 Luis Villa 2002-11-25 19:08:27 UTC
Marking critical (data loss is part of the definition of 'critical')
and 'high' - we absolutely can't be shipping with problems that cause
data loss. 
Comment 3 Alexander Larsson 2002-12-13 16:40:55 UTC
Wow. This one is a royal pain in the ass to fix.
What happens is that nautilus doesn't grokk that the file is in a
subdir of the destination, so when you say remove it removes the
destination first, which means the source goes to.

handle_name_conflicts in gnome-vfs-xfer.c needs to check if the source
is in a subdir of the target. If so it needs to return an error.

This is quite hairy to do. But here is an algorithm that works:
given source and dest, if dest is a dir, start at fully resolve
symlinks for source and stat each directory up to the root. If ever a
dir has the the same inode, dev as dest we fail.
Comment 4 Alexander Larsson 2002-12-18 12:33:29 UTC
I checked in a fix to gnome-vfs:
2002-12-18  Alexander Larsson  <alexl@redhat.com>

	* libgnomevfs/gnome-vfs-private-utils.h:
	* libgnomevfs/gnome-vfs-utils.c:
	(_gnome_vfs_uri_resolve_all_symlinks_uri),
	(_gnome_vfs_uri_resolve_all_symlinks),
	(_gnome_vfs_uri_is_in_subdir):
	New functions. Not exported since we're in a freeze, but might
	be nice to export later.
	
	* libgnomevfs/gnome-vfs-xfer.c:
	(move_source_is_in_target),
	(handle_name_conflicts):
	Handle the case when moving a file over a directory it is contained in.
	(Bug #99346)
	
	* test/Makefile.am:
	* test/test-resolv.c: (main):
	* test/test-subdir.c: (main):
	Some test code.

Comment 5 Pasupathi 2002-12-19 16:22:55 UTC
Updated CC list for internal tracking..
Thanks.