GNOME Bugzilla – Bug 314139
Same filesystem drag-and-drop of a readonly file should gracefully degrade to a "copy"
Last modified: 2008-10-12 15:25:12 UTC
Try this: * Create a file as user A, give it 0664 permissions. * Try to drag and drop the file as user B. You'll get a "couldn't move file due to lack of permissions" dialog. Suggestion: Instead of presenting an error dialog, silently degrading to a "copy" operation would be easier. Otherwise, the user must do a more tedious copy/paste.
nelson@gnelson ~/Desktop $ su Password: gnelson Desktop # echo "hola" > hola.txt gnelson Desktop # chmod 0664 hola.txt gnelson Desktop # chown pedro:users hola.txt gnelson Desktop # exit exit nelson@gnelson ~/Desktop $ ll hola.txt -rw-rw-r-- 1 pedro users 5 ago 22 09:57 hola.txt nelson@gnelson ~/Desktop $ whoami nelson nelson@gnelson ~/Desktop $ nautilus (*I am able to drag-and-drop the file without problems*) Probably the error you are getting is because the folder containing the file is also owned by user A and have some kind of permission, in that case nautilus cannot change the ownership of a folder to let you copy the file. Besides it's strange because imho the copy operation is more restrictive than move operation, I mean, to copy a file you need read permission on it, to move it you don't need it (I think just need execution permission). I'm using nautilus 2.10.1
I foolishly neglected to mention the parent directory's permissions (also important). They look like: (user has r/w/browse everyone else has r/browse) drwxrwxr-x 16 testuser testuser 4096 2005-08-22 04:26 . File operations: * Copy (needs read on the file and write on the destination directory) * Move (needs write on the source and destination directory, but nothing on the file)
Adam, I think your idea is not conceivable because we cannot delete the file after copy it. If we are going to silently simulate a "move operation" by "copy the file and if succeded delete the source file", in this case we can copy the file but cannot delete it. In your original bug report you don't mention the delete operation, don't know why. So, for the record: * Delete (needs write both in the file being deleted and in folder that contains it) Do you still think your idea is conceivable ?
Just a correction of my last comment: * Delete (only needs write in the folder that contains the file to be deleted)
Sorry if I was unclear. I meant: fall back to a simple copy operation if we cannot move the target. This would leave the original intact.
Silently doing something else than what the user requested doesn't sounds like a good idea to me. Maybe we should rather add a "Copy Folder"/"Copy File" button to the error dialog. Usability team, any opinions?
Created attachment 51763 [details] Mockup
Mass changing Nautilus version for bugs that have GNOME 2.13 version info.
*** Bug 331643 has been marked as a duplicate of this bug. ***
Created attachment 66519 [details] [review] fix for this bug. must have http://bugzilla.gnome.org/attachment.cgi?id=63939&action=view applied before it will apply cleanly.
Fix this by basically checking if the source uri's parent is readonly, if so, then do a copy not move.
Re comment #6... the change indeed shouldn't be "silent", but the cursor should change from the "move" to the "copy" cursor when only a copy operation is available. This is how it works on OSX.
Any progress on this bug? No comments for the last 6 months! It's incredibly annoying, and also has silly consequences - I can drag and drop a read-only file into my remote server folder on the desktop, but when I try and drag and drop it to the desktop itself, it fails. I think this should be quite a high priority bug!
Still no progress? This bug is still an enhancement, yet it's quite embarrassing to show friends that despite all the cool features it has, Gnome can't do basic drag and drop copying properly. Please work on this!
This is a serious glitch and should have been fixed over two years ago. We must fix it with FULL FORCE. Oh man! Yeeeeeeeeeaaaaaaahhhhhhhh. I mean, just so you all know what I mean here. Just if anyone was wondering. Just FYI
*** Bug 509120 has been marked as a duplicate of this bug. ***
This is not an ehhancement, but actually a bug, because it makes no sense to have a "move" option active for read only locations (it may make sense though with PolicyKit integration).
Patch is obsolete, setting status. But the approach might work.
that's still an issue
Created attachment 115421 [details] [review] Patch to resolve bug Hi, this patch uses the same approach of the previous patch but updated to use GIO, it's working well, you can test it by dragging a file from /etc and drop it in your home dir, with this patch the file gets copied, but without it the file is moved and so an error is display because we cannot delete the source file..
Ideally we should use the already implemented NautilusFile machinery to do this for us, as we should in most cases already have that information cached within it. Secondly, synchronous I/O inside of Nautilus is bad; as it has already been shown with the Places sidebar drag-and-drop bug, one instance of synchronous access on a slow mount means Nautilus freezes while we wait. Setting patch status. Thanks for your work!
Thanks for your quick response, (In reply to comment #21) > Ideally we should use the already implemented NautilusFile machinery to do this > for us, as we should in most cases already have that information cached within This should not be hard to add. > it. Secondly, synchronous I/O inside of Nautilus is bad; as it has already been > shown with the Places sidebar drag-and-drop bug, one instance of synchronous > access on a slow mount means Nautilus freezes while we wait. Making this asynchronous seems like tedious work because the function where this happens is synchronous and sets whether the operation is copy or move, and the corresponding emblem.. Alternatively, we could put a local filesystem check around this, so we would only do this synchronous I/O when the files are in local filesystem, which also happens to be the more frequent and typical user case. > Setting patch status. Thanks for your work! > Thanks for your review..!
*** Bug 402947 has been marked as a duplicate of this bug. ***
Created attachment 119762 [details] [review] Patch using NautilusFile Hi, I've made a new patch, this only uses the existing NautilusFile cached information, instead of using gio to retrieve it, if there's no an existing NautilusFile object we just return FALSE. But the good thing is that we always have that NautilusFile present, because it is the parent folder of the file we are dragging, and if we are dragging it then it means Nautilus had the parent folder already opened and so its NautilusFile is cached.
Created attachment 120440 [details] [review] Commited patch After reviewing[1] in nautilus mailing list, this is the patch that finally got commited, marking as fixed. [1] http://mail.gnome.org/archives/nautilus-list/2008-October/msg00029.html