RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 970394 - nautilus Format... does nothing
Summary: nautilus Format... does nothing
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: udisks2
Version: 7.0
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: pre-dev-freeze
: 7.1
Assignee: Tomas Smetana
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1077310
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-03 23:34 UTC by Mark Gordon
Modified: 2021-09-06 12:33 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-05-11 11:12:57 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
screenshot (9.00 KB, image/png)
2014-03-13 11:48 UTC, Martin 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 76178 0 None None None Never

Description Mark Gordon 2013-06-03 23:34:36 UTC 
Description of problem:
The Format... option available from the context menu in the sidebar for thumb drives etc. doesn't work.

Version-Release number of selected component (if applicable):
nautilus-3.8.1-1.el7
gnome-disk-utility-3.8.0-1.el7

How reproducible:
100%

Steps to Reproduce:
1. Insert a thumb drive.
2. Make the sidebar visible (F9) if it isn't already.
3. Right-click the thumb drive in the sidebar and select "Format..."
4. Pick any combination of Erase and Type; the choice doesn't seem to make any difference.
5. Click the Format... button.
6. Click the Format button in the confirmation dialog.

Actual results:
Volume is unmounted, but device remains visible.  Clicking the device (which has the side effect of mounting the device) shows unmodified contents.  Properties shows the original filesystem type preserved.

Expected results:
Volume disappears during formatting (as happens with gnome-disks), reappears, on mounting has previous contents gone, new filesystem type.

Additional info:
Other than the volume not disappearing from under Devices, there are several other differences in behavior from "gnome-disks --block-device $DEV --format-device"
- I don't have ntfsprogs installed, so mkntfs isn't present.  gnome-disks therefore rightly complains if I try to format a device with ntfs; nautilus doesn't, but should.
- If I try to format a device with LUKS + Ext4 and select a password of fewer than eight characters, gnome-disks complains; nautilus doesn't, but should.
Comment 2 jakobunt 2013-09-21 17:42:58 UTC 
Same on F19, upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=703424
Comment 3 Matthias Clasen 2013-10-30 02:47:30 UTC 
the Format... menuitem seems to work fine in quick testing here.
Comment 4 Lenny Szubowicz 2014-02-04 20:45:18 UTC 
So, I just ran into the same problem on RHEL-7.0-20140127.0 (snapshot 4) installed.

Attempt to format a USB drive as vfat from a Nautilus window does not result in any error messages, but the device certainly has not been formatted. All the previous content is still there.

I'm logged in as root, and I can format the USB flash drive from a shell prompt.

# mkdosfs -v -n test2 /dev/sdb1

                                 -Lenny.
Comment 5 Matthias Clasen 2014-02-19 19:54:58 UTC 
This should be fixed in gnome-disk-utility-3.8.2-5.el7
Comment 6 Martin 2014-03-13 11:48:48 UTC 
Created attachment 873938 [details]
screenshot

This is fixed for flashdrives formated as VFAT, but not for "iso9660". "Error formating volume" dialog appears in Gnome Disks.

Steps to reproduce:
1. dd "Fedora-Live-Desktop-x86_64-20-1.iso" onto flashdrive and sync.
2. Remove flashdrive.
3. Insert flashdrive (but don't open it in Nautilus.
4. In Nautilus, right-click on device and select "format".
5. Click on "Format...".
6. After 5 minutes click on device in Nautilus.

Results:
1. Device is still named "Fedora-Live...".
2. I still see content of Fedora-Live-Desktop-x86_64-20-1.

3. After I disconnect flashdrive and connect back. I can't see it in Nautilus. When I run Gnome Disks, I see "Error formating volume" dialog and flashdrive with "Unknown" volume.
Comment 7 Matthias Clasen 2014-03-13 12:59:32 UTC 
that sounds like a different issue. what you describe here ("Error dialog appears") is very different from the subject of this bug ("nothing happens")
Comment 8 Martin 2014-03-13 13:55:59 UTC 
It actually does nothing in Nautilus, it's same behavior described in #0.

Error in Gnome Disks is additional information, which can help developer trace this issue.

My point is, flashdrive format in Nautilus is not fixed for flashdrive containing iso9660 filesystem.
Comment 9 Matthias Clasen 2014-03-13 15:31:02 UTC 
I can reproduce this, both on rhel7 and on current f20 and rawhide.
Comment 10 Ondrej Holy 2014-03-13 17:43:23 UTC 
Same error is possible to reproduce just using the gnome-disk-utility:
1/ insert drive with iso9660
2/ format it in the gnome-disk-utility
3/ mount it in the gnome-disk-utility and the error appears in a short time
Comment 11 Ondrej Holy 2014-03-14 15:13:42 UTC 
This is probably udisks bug. For more details see upstream bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76178
Comment 12 Ondrej Holy 2014-03-17 19:57:29 UTC 
Just a quick note...

It is possible to format a whole device:
Gnome Disks -> Drive -> Format
gnome-disks --block-device /dev/sdb --format-device

But it fails to format just a volume on iso9660 if there is multiple volumes:
Gnome Disks -> Volume -> Format and also Nautilus -> Devices -> Format
gnome-disks --block-device /dev/sdb1 --format-device
Comment 13 Ondrej Holy 2014-03-27 16:55:45 UTC 
The problem is Fedora image format (http://mjg59.dreamwidth.org/11285.html), because there is partition table inside first partition (hope I'm not talking nonsense). 

Wipefs wipes everything on /dev/sdb1 (Bug 1077310). So it removes all partitions and also the partition table. The error occurs, because it wanted to re-read the removed partition table: 
/dev/sdb1: calling ioclt to re-read partition table: Invalid argument

Udev doesn't see the change, because of partition table isn't re-read for /dev/sdb probably:
$ udevadm info --name /dev/sdb1
E: ID_FS_TYPE=iso9660

However there is still problem even if udisks have fresh information, because we don't have /dev/sdb1 partition to continue formatting...
Comment 14 Ludek Smid 2014-03-28 12:12:09 UTC 
This is corner case scenario, moving to RHEL 7.1 based on discussion on Mar-28.
Comment 18 Vladimir Benes 2015-05-11 11:12:57 UTC 
As the original issue was closed in 3.8.2. I am closing as current release. If you anyone feel that the Fedora issue should be fixed, please file it upstream first.
Note You need to log in before you can comment on or make changes to this bug.