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 703179 - Cannot copy files to USB stick if previous stick was read-only
Cannot copy files to USB stick if previous stick was read-only
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: general
3.26.x
Other Linux
: Normal normal
: future
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 557138 (view as bug list)
Depends on: 787731
Blocks:
 
 
Reported: 2013-06-27 11:29 UTC by Ewan.LEBIDEAU-CANEVET
Modified: 2021-06-18 15:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
nautilus-directory: handle change events (5.13 KB, patch)
2017-09-15 17:42 UTC, Nelson Benitez
none Details | Review
nautilus-directory-async: don't free right away a callback passed object (1.36 KB, patch)
2017-09-17 10:43 UTC, Nelson Benitez
none Details | Review
nautilus-directory: handle change events (5.21 KB, patch)
2017-11-08 14:51 UTC, Nelson Benitez
none Details | Review

Description Ewan.LEBIDEAU-CANEVET 2013-06-27 11:29:27 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
Comment 1 Ildar 2013-08-24 20:48:17 UTC
Might be dup of https://bugzilla.gnome.org/show_bug.cgi?id=557138
Comment 2 Christian Stadelmann 2014-10-06 10:51:53 UTC
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.
Comment 3 Jonathan 2015-08-22 14:04:30 UTC
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
Comment 4 Jonathan 2015-08-22 14:13:08 UTC
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?
Comment 5 Carlos Soriano 2015-08-24 07:43:22 UTC
yes, everything is cached, but we monitor files so it should catch that. Maybe it lost the monitor at some point...
Comment 6 garrett.mitchener 2016-08-19 17:35:58 UTC
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.
Comment 7 seanbw 2016-09-22 15:27:13 UTC
Also affects a SATA drive
Comment 8 morglum 2016-10-03 09:51:08 UTC
Same issue with Ubuntu 16.04.1 & SATA LUKS-encrypted drive; samba share read only from local network as well.
Comment 9 Carlos Soriano 2016-10-07 13:30:06 UTC
I cannot reproduce in 3.22, partitions get unmounted and mounted again when formatting in disks, and it correctly has the permissions.
Comment 10 Christian Stadelmann 2016-10-16 15:53:48 UTC
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
Comment 11 Carlos Soriano 2016-10-26 18:14:23 UTC
(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
Comment 12 Antony Jones 2017-01-02 12:48:04 UTC
Can confirm this bug still exists:

$ nautilus --version
GNOME nautilus 3.20.3
Comment 13 Christian Stadelmann 2017-04-05 13:54:05 UTC
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.
Comment 14 Nelson Benitez 2017-09-15 17:40:05 UTC
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
Comment 15 Nelson Benitez 2017-09-15 17:42:30 UTC
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.
Comment 16 Nelson Benitez 2017-09-15 17:51:05 UTC
*** Bug 557138 has been marked as a duplicate of this bug. ***
Comment 17 Nelson Benitez 2017-09-17 10:43:32 UTC
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.
Comment 18 Ernestas Kulik 2017-09-17 10:49:18 UTC
(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.
Comment 19 Ernestas Kulik 2017-09-17 10:50:55 UTC
(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.
Comment 20 Ernestas Kulik 2017-09-17 11:00:06 UTC
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.
Comment 21 Nelson Benitez 2017-09-17 13:08:04 UTC
(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.
Comment 22 Nelson Benitez 2017-11-05 08:48:46 UTC
(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.
Comment 23 Carlos Soriano 2017-11-08 11:19:50 UTC
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
Comment 24 Nelson Benitez 2017-11-08 14:51:56 UTC
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!
Comment 25 André Klapper 2021-06-18 15:55:55 UTC
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.