GNOME Bugzilla – Bug 703179
Cannot copy files to USB stick if previous stick was read-only
Last modified: 2021-06-18 15:55:55 UTC
User can notice that if first he inserts a read-only USB stick, he is unable to copy files to another stick that has full permissions. Steps : 1. Boot System 2. In homescreen open nautilus 3. Insert a USB stick that is read-only (my suggestion is a Fedora 19 Beta boot stick made with DD, this is what i used for the test, i could not paste any files on it since paste was greyed out) 4. Remove the stick and insert a normal stick 5. Try to copy paste on the stick 6. Observe it's says read-only no matter what permissions it has 7. Close nautilus and reopen 8. Observe still you cannot copy Expected outcome You can copy on the stick since you have full permissions Actual outcome You cannot copy on the stick, reboot of system required Note : this reproduced on Fedora 19 Beta
Might be dup of https://bugzilla.gnome.org/show_bug.cgi?id=557138
Still an issue with nautilus 3.14.0 from F21 Alpha. What I did: 1. inserted USB stick formatted read-only 2. opened nautilus 3. chose "format" from nautilus context menu on stick 4. chose default preferences (FAT, no overwrite) 5. waited until format finished 6. mounted USB stick with nautilus 7. tried to copy files onto USB stick The strange thing is: the filesystem is mounted with read permissions in /run/media/[username]/[partition-name]/ and I can create/modify/delete/copy files using the (gnome) terminal. So this seems to be no bug in gvfs. Permissions are 700 and me and my group are owner of the folder.
Seems to have the same thing here. USB flash drive San Disk Cruiser Fit was originally read only when nautilus first saw it. Then formatted with DISKS. Can now copy to it with terminal, but nautilus refuses, claiming the destination is read only. Tried reformatting, remounting and assorted vodou but finds no way around it. I'd be happy to help troubleshooting this if you tell me what tests I can run for you. Fedora 22. nautilus.x86_64 3.16.2-2.fc22 Might also be on launchpad https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1021375
And it just got really interesting. After fighting this issue for hours, I gave up and resolved to copying by terminal. By force of habit, I accidently used nautilus once more to copy, after copying a batch of files by terminal, and presto, it works. Nautilus now copies files without complaining. I don't understand what happens here. Some cache of file / partition permissions that went old and was refreshed?
yes, everything is cached, but we monitor files so it should catch that. Maybe it lost the monitor at some point...
I just ran into this problem with nautilus 3.20.2 on Fedora 24. I inserted a thumb drive that had an ISO9660 file system (Linux installer), repartitioned it, reformatted the one partition as FAT32. Nautilus refused to create new directories in or copy files to the thumb drive. I could check in a terminal that I had full write access. I went to a terminal and ran "pkill nautilus" to kill all nautilus processes, then restarted it. Then nautilus could write to the thumb drive normally.
Also affects a SATA drive
Same issue with Ubuntu 16.04.1 & SATA LUKS-encrypted drive; samba share read only from local network as well.
I cannot reproduce in 3.22, partitions get unmounted and mounted again when formatting in disks, and it correctly has the permissions.
I can still reproduce as described before: (In reply to Christian Stadelmann from comment #2) > Still an issue with nautilus 3.14.0 from F21 Alpha. > What I did: > 1. inserted USB stick formatted read-only > 2. opened nautilus > 3. chose "format" from nautilus context menu on stick > 4. chose default preferences (FAT, no overwrite) > 5. waited until format finished > 6. mounted USB stick with nautilus > 7. tried to copy files onto USB stick Note that this reproducer only works if the exact partition name matches, e.g. /dev/sdf1. Reproducer doesn't work if partition name changes e.g. to /dev/sdg or /dev/sdf2. Software versions: gtk3-3.22.1-2.fc25.x86_64 glib2-2.50.1-1.fc25.x86_64 nautilus-3.22.1-1.fc25.x86_64 gvfs-1.30.1-1.fc25.x86_64 kernel-4.8.1-1.fc25.x86_64
(In reply to Christian Stadelmann from comment #10) > I can still reproduce as described before: > > (In reply to Christian Stadelmann from comment #2) > > Still an issue with nautilus 3.14.0 from F21 Alpha. > > What I did: > > 1. inserted USB stick formatted read-only > > 2. opened nautilus > > 3. chose "format" from nautilus context menu on stick > > 4. chose default preferences (FAT, no overwrite) > > 5. waited until format finished > > 6. mounted USB stick with nautilus > > 7. tried to copy files onto USB stick > > Note that this reproducer only works if the exact partition name matches, > e.g. /dev/sdf1. Reproducer doesn't work if partition name changes e.g. to > /dev/sdg or /dev/sdf2. > > Software versions: > gtk3-3.22.1-2.fc25.x86_64 > glib2-2.50.1-1.fc25.x86_64 > nautilus-3.22.1-1.fc25.x86_64 > gvfs-1.30.1-1.fc25.x86_64 > kernel-4.8.1-1.fc25.x86_64 Interesting note, thanks
Can confirm this bug still exists: $ nautilus --version GNOME nautilus 3.20.3
Still present with nautilus-3.22.3-1.fc25.x86_64. Workaround: Terminate (SIGTERM, or just wait some time) nautilus before accessing the new USB stick. Works even if the stick is already mounted. Additional note: Even though nautilus tells me the stick is read-only (and thus I cannot copy or create files or folders on it), I can still delete files just fine.
Well, I've been investigating this bug and have come to conclusions in the form of patches. I could reproduce this bug efficiently (without needing to re-format constantly) as I have a usb pendrive with a write protection switch, like in this image[1], which means you can set the usb partition be readonly or rw just by flipping the switch. There's actually two bugs in here, one in nautilus and one in gio. 1) Nautilus file monitoring discards CHANGE events for files that are unknown to Nautilus (i.e. those that nautilus_file_get_existing() returns NULL for them), that is fine. But what happens to the usb mountpoint directory created when usb is inserted, in the conditions of this bug, is that inotify fires two consecutive events, a NEW + CHANGE events, where the NEW event comes with a wrong "filesystem::readonly" value and the CHANGE event comes with the correct updated value. The problem is Nautilus is still processing the NEW event when the CHANGE event arrives and it's discarded as the NEW event has not finished and so there's no corresponding NautilusFile yet. The patch fixes this issue by adding to a list the files of CHANGE events received in this situation and processing them after the directory is finished adding the new files. 2) The previous fix makes the mountpoint directory of the inserted usb to show correct permissions (ie. correct state for Create/Cut/copy contextual menu entries) but if you copied a file from eg. your home folder, and try to paste it inside the mounted directory, Nautilus showed an error saying the destination filesystem is readonly and cannot paste the file. This is caused by a call from nautilus to g_file_query_filesystem_info() which returns a file_info with "filesystem::readonly" set to TRUE, which is wrong as the current mount is rw. The exact call from nautilus is this[2]. The bug is caused by the mount info cache in GIO not being dropped when a mount-change occurs, because it was using mtime monitoring for /proc/ files which is wrong. More details in the blocking bug 787731 . So, with these nautilus and gio patches applied I could no longer reproduce any buggy behaviour when re-mounting as rw a previous ro mount. [1] https://imgur.com/a/AYWkU [2] https://gitlab.gnome.org/GNOME/nautilus/blob/master/src/nautilus-file-operations.c#L3547
Created attachment 359870 [details] [review] nautilus-directory: handle change events for files that were still not known to nautilus because they were in the midst of being added to Nautilus. This happens when eg. inotify fires two consecutive NEW + CHANGE events for a new file, and it's important to handle the CHANGE event as the file may have changed its properties with respect the ones reported at the time the NEW event fired. A case this happens is for mountpoint directories of removable devices, as seen in the referenced bug below. We now queue CHANGE events received for files unknown to Nautilus only when the parent folder is currently adding new files. When the folder finish adding the new files, we then process the list of queued files. If there are still files unknown to Nautilus in this list, they will be ignored as before.
*** Bug 557138 has been marked as a duplicate of this bug. ***
Created attachment 359925 [details] [review] nautilus-directory-async: don't free right away a callback passed object instead let's do it from the callback itself. ----------- This is just a misc patch for a dangerous free I saw while working on this bug.
(In reply to Nelson Benitez from comment #17) > Created attachment 359925 [details] [review] [review] > nautilus-directory-async: don't free right away a callback passed object > > instead let's do it from the callback itself. > > ----------- > > This is just a misc patch for a dangerous free I saw while working on this > bug. How is it dangerous? The source object is reffed on task creation.
(In reply to Ernestas Kulik from comment #18) > (In reply to Nelson Benitez from comment #17) > > Created attachment 359925 [details] [review] [review] [review] > > nautilus-directory-async: don't free right away a callback passed object > > > > instead let's do it from the callback itself. > > > > ----------- > > > > This is just a misc patch for a dangerous free I saw while working on this > > bug. > > How is it dangerous? The source object is reffed on task creation. Wow, I just realized how dumb a question that is. Sorry for the waves.
Review of attachment 359925 [details] [review]: I really need to take an hour to think before responding. Let’s go through what happens here. nautilus_file_get_location() is called, which, long story short, returns a reffed GFile. After that, g_file_query_filesystem_info_async() is called, which creates a GTask with “location” as its source object, which, you guessed it, gets reffed. This patch really changes nothing, so I’m rejecting it by that logic. By all means, correct me if I’m wrong.
(In reply to Ernestas Kulik from comment #20) > Review of attachment 359925 [details] [review] [review]: > > I really need to take an hour to think before responding. > > Let’s go through what happens here. > > nautilus_file_get_location() is called, which, long story short, returns a > reffed GFile. After that, g_file_query_filesystem_info_async() is called, > which creates a GTask with “location” as its source object, which, you > guessed it, gets reffed. > > This patch really changes nothing, so I’m rejecting it by that logic. By all > means, correct me if I’m wrong. Yes, I sent the patch just from spotting this pattern that look bad from the outside, but didn't dig into GTask code to see if it reffed'd the source object. Sorry for the inconvenience.
(In reply to Nelson Benitez from comment #14) > Well, I've been investigating this bug and have come to conclusions in the > form of patches. > > I could reproduce this bug efficiently (without needing to re-format > constantly) as I have a usb pendrive with a write protection switch, like in > this image[1], which means you can set the usb partition be readonly or rw > just by flipping the switch. > > There's actually two bugs in here, one in nautilus and one in gio. Ping. The gio bug was fixed in bug 787731 so it would be nice to have a complete fix in Nautilus side too.
Review of attachment 359870 [details] [review]: Looks good overall, thanks Nelson! Just some nitpicks: ::: src/nautilus-directory-async.c @@ +611,3 @@ } + + if (directory->details->new_files_in_progress_changes != NULL) this block is missing a space of identation @@ +926,3 @@ + + directory->details->new_files_in_progress_changes + = g_list_reverse (directory->details->new_files_in_progress_changes); same, function call and first parameter in the same line ::: src/nautilus-directory-private.h @@ +106,3 @@ + /* List of GFile's that received CHANGE events while new files were being added in + * that same folder. We will process this CHANGE events after new_files_in_progress + * list is finished. See Bug 703179 for a case this happens. */ I think "for a case when this happens" is more correct wording. ::: src/nautilus-directory.c @@ +1261,3 @@ file); } + else sneaky tab @@ +1269,3 @@ + { + dir->details->new_files_in_progress_changes + = g_list_prepend (dir->details->new_files_in_progress_changes, put "=" and the function call + first parameter in the same line. @@ +1273,3 @@ + } + + if (dir != NULL) Use {} for single lines too. @@ +1275,3 @@ + if (dir != NULL) + nautilus_directory_unref (dir); + if (parent != NULL) ditto
Created attachment 363226 [details] [review] nautilus-directory: handle change events for files that were still not known to nautilus because they were in the midst of being added to Nautilus. This happens when eg. inotify fires two consecutive NEW + CHANGE events for a new file, and it's important to handle the CHANGE event as the file may have changed its properties with respect the ones reported at the time the NEW event fired. A case this happens is for mountpoint directories of removable devices, as seen in the referenced bug below. We now queue CHANGE events received for files unknown to Nautilus only when the parent folder is currently adding new files. When the folder finish adding the new files, we then process the list of queued files. If there are still files unknown to Nautilus in this list, they will be ignored as before. -------- Updated patch. Thank you Carlos for review!
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.