GNOME Bugzilla – Bug 545684
G_FILE_ATTRIBUTE_ID_FILESYSTEM is wrong
Last modified: 2008-08-01 19:33:59 UTC
Please describe the problem: Hi!, G_FILE_ATTRIBUTE_ID_FILESYSTEM[1] is wrong in some case, in concrete when you have a file in the Trash, and you drag and drop it to a folder in your Home, the move operation is done by copying the file (as if they were on different filesystems) instead of a fast move operation. Steps to reproduce: 1. Select a big file in nautilus, for example a file of 80MB, press Delete so it is moved to the Trash. 2. Open the Trash, drag the aforementioned file and drop it in its original location, as if you were recovering it. Actual results: A nautilus dialog appears saying the file is being moved while a progress bar shows how the file is being copied, the operation lasts more than 10 seconds as copying a 80MB file is not a quick operation. Expected results: A nautilus dialog appears saying the file is being moved and the file gets moved quickly because it doesn't need to copy the file as both the Trash and the target directory are on the same filesystem. Does this happen every time? Yes Other information: I assume you have your Trash and the directory you drop the file on the same filesystem, which is the normal situation.
(In reply to comment #0) > Please describe the problem: > Hi!, > G_FILE_ATTRIBUTE_ID_FILESYSTEM[1] is wrong in some case, in concrete when you Forget to put the reference to [1].. [1] http://library.gnome.org/devel/gio/unstable/GFileInfo.html#G-FILE-ATTRIBUTE-ID-FILESYSTEM:CAPS
What would be useful here is the output of /bin/mount and gvfs-mount -l and the source and destination paths. Which GIO/GVFS backends are used to store the source and destination folders?
source and destination paths are: trash:///_algo.zip file:///home/nelson/Escritorio Both source and destination paths are in the same ext3 partition of my linux box. The backend should be the default I think..
Well I've just seen my system has a process called "gvfsd-trash" so the trash:// uri probably has its own gvfs backend...
I can confirm this, move a file to Trash is fast, moving it from Trash is slow (eg, copy+delete). I'm not sure if this is a bug in nautilus or in gio. Is nautilus calling g_file_copy or g_file_move?
I'm pretty confident it's a bug in GIO, in concrete in the G_FILE_ATTRIBUTE_ID_FILESYSTEM attribute, because nautilus has a function called check_same_fs, which in turn just compares the G_FILE_ATTRIBUTE_ID_FILESYSTEM of both files passed as parameters, this function returns FALSE for the two paths I said in comment 3, so if nautilus thinks the two files are in different filesystems it's normal that makes the operation as copy+delete, if G_FILE_ATTRIBUTE_ID_FILESYSTEM were the same for both files then probably nautilus would do a real move operation. check_same_fs() is in http://svn.gnome.org/viewvc/nautilus/trunk/libnautilus-private/nautilus-dnd.c?view=markup and nautilus_file_get_filesystem_id() is in http://svn.gnome.org/viewvc/nautilus/trunk/libnautilus-private/nautilus-file.c?view=markup
Perhaps the Trash backend is not returning the file system id of the underlying filesystem? Could that be the case?
Yes, that could be the case, someone familiarized with gio code could check that, I'll try it but I'm new to gio code...
For a file in trash:/// id::filesystem: type='trash',mount_prefix='/' id::file: l2054:2195866 For a file on the same file system as the file in trash: id::filesystem: l2054 I think this is a bug in nautilus, check_same_fs should be a bit more intelligent when deciding when to copy or move a file.
This is not just about the same_fs_check, the problem is that we do not provide a move implementation across modules for moving files out of trash, i.e. bug 529971. I'm marking this one as a duplicate. *** This bug has been marked as a duplicate of 529971 ***