MediaWriter icon indicating copy to clipboard operation
MediaWriter copied to clipboard

Display of available devices is insufficient

Open stefanseefeld opened this issue 9 years ago • 5 comments

After selecting an image to write the user is presented with a choice of available devices. At least in my case (on Fedora 24) that list is not useful at all. For example, I see "090c 1000 (2.0 GB)" but have no idea what device that is. If I click the "Write" button, I get another dialog (to enter my sudo credentials) where I learn that this is actually my (USB-connected) printer.

There ought to be a way to display more complete device information (such as the associated device file in /dev).

Also (though that might be worth a separate issue), some devices are missing from the list, so it would be useful to have a command-line interface (for example) to specify a device name to attempt to write to.

stefanseefeld avatar Nov 22 '16 20:11 stefanseefeld

A printer, really? If this actually happens, it's probably an issue of UDisks2, udev or even the kernel. Please report this to the Fedora Bugzilla. I think the udisks2 package would be a good start. Or maybe try upgrading to Fedora 25 first and then try it again (udisks2 was replaced by storaged in F25).

It's possible some devices would be left out of the list of devices you get in FMW. However, considering the issue of getting a printer in udisks could be a completely different problem.

MartinBriza avatar Nov 23 '16 15:11 MartinBriza

OK, so let's keep the printer issue out. The main point I wanted to report however remains: the names being reported may not always be useful. In fact, in my case I did get a list of storage devices ("Sandisk ...", etc.), but all associated with non-existent devices ("/dev/sde", which didn't correspond to an existing device.) Having only storage device names may work in an ideal world (if these names all correspond to existing devices, and are recognizable by the user), but as soon as that isn't the case (multiple ambiguous names, names without recognizable devices, etc.) the user needs to be able to figure out which device to pick, or even forcibly override the list.

stefanseefeld avatar Nov 23 '16 16:11 stefanseefeld

While I agree in the ideal world you usually don't get a precise name every time and there should be a backup way of getting a name for the device, I think your problem is elsewhere. In case there's a name collision or there's not a human-readable name, I'm going to add a fallback mechanism of showing some more device information that could be usable for identifying the right drive.

If the names in FMW don't correspond to the actual block devices you've got in your /dev folder, there's definitely something rotten in your system. Please check (for example) Gnome Disks or some other tool that utilizes UDisks2 to see if the devices are right there. Or, if you're technical enough, please try traversing through the devices in UDisks over D-Bus (qdbusviewer is quite usable for that). There you will see what FMW sees, including the device path, device vendor and its model.

MartinBriza avatar Nov 23 '16 16:11 MartinBriza

I worked on fixing the drive detection code on Linux. However, if your printer has some internal storage and it's connected over USB, it will be reported in Fedora Media Writer. If you still suffer from some issues, feel free to either reopen this report or create a new one.

MartinBriza avatar Jan 10 '17 15:01 MartinBriza

I'd like to reopen this ticket, the list of USB drives is effectively ambiguous without device paths. Imagine you have 2 or more thumb drives of the same model plugged in and, for instance, they show up in the drop-down box as:

  • USB DISK 2.0 (15.9 GB)
  • USB DISK 2.0 (15.9 GB)
  • USB DISK 2.0 (15.9 GB)

Ok, so, whose idea was it to omit device paths? This is an insane UI/UX decision. For reference, I'm using version 5.1.2 from within the live USB of Fedora Workstation 41 (running from one of those thumb drives 🙃).

EDIT: The same problem also exists in the latest release (5.2.3).

bit2shift avatar Feb 17 '25 04:02 bit2shift