The goal is to make it easy for everybody to move data around and manage it. It initially covers things like support for long volume labels, uniformity between the drivemount applet and places and more items for volume context menus.


Ubuntu has some usability benefits over Microsoft Windows in this area, but there are some important places where Windows is easier. Those are formatting, and setting volume labels. Tasks that should be simple and easy to perform and to discover how to perform are difficult in both Ubuntu and Windows leaving no good option for user. The changes required are small, probably requiring little to no infrastructure changes and only a bit of commandline tool integration.

Use cases

  1. Places (in Nautilus and in panel menu) and desktop only show short volume labels (tested with FAT16 usb drive).
    • User has two USB drives with volume labels set by a knowlegeable friend using mlabel from mtools. These labels are "Bob's USB Drive" and "Bob's USB Drive (the new one)". With both plugged in, Bob expects to see the correct volume labels rather than ones that are hard to distinguish. Suggestion: Support long volume labels in nautilus, places, and on the desktop.
  2. The drivemount applet displays only a manufacturer specified string, and does not display the volume label, making it difficult to identify which volume one is (un)mounting.
    • Bob uses two USB drives with different labels but of the same model. He prefers to use the drivemount applet as it is always available. Bob wants to see which USB drive he is about to unmount if he has both plugged in at the same time. Suggestion: Show the same volume label as places and the desktop in addition to the manufacturer specified string. Discussion: For unmounted devices, the applet could attempt to guess the filesystem type and use a filesystem specific tool to find the volume label whenever the user brings up the menu.
  3. It is non-obvious how to set the volume label of a filesystem on a removable device.
    • Bob has many floppy disks and many USB drives but none of them has a meaningful volume label (since the manufacturer pre-formatted them). Bob didn't format them with volume labels before beginning to use them as he used them for ad-hoc purposes until he worked out how he would organise his data. Now Bob would like to set sensible volume labels so he can see at a glance what volumes are mounted, or plugged in. Suggestion: Add a menu item for volume icons along with the existing mount/unmount items. This menu item should bring up a dialog where it is easy to change the volume label.
  4. main doesn't seem to contain tools to format rewritable DVDs with udf filesystems, nor is there a simple user interface for it.
    • Suggestion: Add a menu item for volume icons along with the existing mount/unmount items. This menu item should bring up a simple dialog where it is easy to trigger a udf filesystem to be made on the cd device. A similar interface could be used to format floppies and USB Drives.


There are two features here, one is basic improvements to the current arrangements, the other is more major surgery.

The basic improvements should be implementable in a fairly straightforward way involving the floppy formatter, whichever code picks of the volume labels currently and the code that currently detects that a volume is mounted (which currently enables the Open option in drive context menus).

The more involved changes require much more discussion and are only appropriate for dapper + 1.


Basic Improvements

  • The volume labels on VFAT filesystems has been noticed to behave like filenames on those filesystems, there can be TWO volume labels, one short and one long. Where a long volume label has been set (eg with mtools) Ubuntu's GUI only displays the short form, which can be nonsensical and possibly confusing. Wherever the volume label is discovered for the GUI should be altered to recognise the presence and extract the long label in the same manner as mtools.
  • The drivemount applet only displays a manufacturer set device string while other locations where mounted media are displayed also show the volume label. The drivemount applet should be modified to obtain the same volume label and display it.
  • The volume label has no way to be changed from the GUI except opening a terminal and running the right command for the relevant filesystem. Add a tool or context menu item for mounted filesystems to change the volume label which runs the appropriate tool for the mounted filesystem.
  • The floppy formatter should be extended to be able to format optical media with packet writing filesystems (eg udf). The udftools package could be used for this

Involved Changes

Note in the below menu item suggestions that the label changing option includes the term "rename" as different user backgrounds will associate different terms with the task. The context menu for all devices should include "Open" and "Advanced", which should show immediately; the "Open" item should attempt to ensure that the drive, media, and filesystem are detected, and mounted. Like other menu's, extra items appropriate to the device should be presented as and when the device and media status is detected; detection should be redone when the context menu is opened unless a filesystem is mounted. "Open" should open a nautilus window immediately which attempts to mount a filesystem, fail to do anything (except present an error dialog describing the media status - or this should be shown in the nautilus window somehow, in a format that user's are less likely to ignore), or appear to show an empty filesystem which will be created upon the user's first attempt to change it - while offering an easy way to do something different before writing anything. The created filesystem should be something appropriate to the type of media (eg, floppy and USB drive should be vfat, CD should be multisession iso9660 w. Rockridge, DVD should be the latest UDF version supported by Ubuntu).

The additional items should be presented something like the following:

  • Floppy drives: If it has a filesystem, should include "Mount" | "Unmount", "Rename/Change Label". If it does not contain a filesystem, should include "Make Filesystem"
  • CD/DVD drives: With a readonly CD/DVD carrying a filesystem it should include "Mount" | "Unmount", "Release". If it contains a rewritable CD and is non-blank and doesn't carry a UDF filesystem with a version supporting deletes the context menu should include "Complete Wipe/Erase/Blank". If it carries a UDF filesystem version supporting deletes, the "Complete Wipe/Erase/Blank" task should still be available from the "Advanced" dialog. If the UDF filesystem version supports changing the label (I don't know if any do, or if any don't), "Rename/Change Label" should be include in the menu. If it contains a writeable CD/DVD or rewriteable, the menu should include "Make Filesystem" - which should make the same filesystem that nautilus would make on first use (see above).
  • USB drives: With a filesystem, should include "Mount" | "Unmount", "Release", "Rename/Change Label". If it does not contain a filesystem, should include "Make Filesystem". Note that "Mount" and "Unmount" behaviour should be changed to be consistent with other drives. Currently the partition block device files are deleted on Unmount, while a CD drive already has a release concept (eject) which can be unified with the concept of releasing the USB drive.

A state transition diagram is under construction at DesktopVolumeManagementStates (Postscript Version).



Data preservation and migration

Outstanding issues

Basic Improvements

  • What happens if the volume label begins to be changed, but the filesystem is swapped out from underneath. How can this utility be made to recognise the situation and fail nondestructively
  • The floppy formatter is under trial for removal from the menus. What is the alternative mechanism for making filesystems from the GUI without having to know all the commandline tools.

Involved Changes

  • Should the concept of making filesystems ever be presented in menus and dialogs other than those labeled advanced.
    • JohnNilsson (Moved out of earlier discussion): Why introduce the user to the concept of a filesystem? Open/Mount could just fail gracefully and tell the user that "This unit isn't prepared for use. Do you want to do it now?". Another problem is that it may take time to read the device, thus the context menu would have to wait.

      • TristanWibberley: I believe this is now addressed, except that I believe the concept of making a filesystem should be discoverable for regular users to become power users, able to put their computers to better effect, and rapidly accessible for power users, and automatically presented only when it makes sense.

    • JohnNilsson (Moved out of earlier discussion in which power user was mentioned): I still belive that "power user" currently is another name for a computer user that can handle a broken system. A "File System" is an implementation detail of the device. A blank media is just a blank media. Choices regarding filesystem types (udf vs. iso, fat vs ext) if they really are necessary should be in an advanced tab only, "default filesystem for this device class".

      • TristanWibberley: Okay, point taken. But I don't agree that "power user" is another name for a computer user that can handle a broken system. That is just belittling the skills of the power user, and the things a power user can achieve that a newbie can't.

      TristanWibberley (Moved out of earlier discussion): I am certain that once nautilus has an empty block device open, one of the *most* obvious actions available in nautilus should be to select a different filesystem to be made. I will agree with [JohnNilsson] on the device context menu to get consensus - this action should therein be relegated to "Advanced".

  • Should operations on media be limited to Open, Release, Advanced, and have a semi-advanced menu appear if one of them can't be done when selected.
  • POSIX semantics on FAT
    • JohnNilsson (Moved out of earlier discussion): A fix to support posix semantics on fat would be better than the user having to decide if fat or ext should be used on a floppy.

      TristanWibberley (Moved out of earlier discussion): I don't think a newbie should face the problem of incompatibilities when transferring such a filesystem to, say, a Microsoft Windows installation. A floppy should have a normal vfat filesystem made on it unless the user knows enough to ask for something else - and then there is little point in bringing umsdos back to life.

  • Should media and drives with mounted filesystems ever be rechecked for status before an attempt to use them fails. Should devices and busses with locking/timely media or drive detection only recheck upon explicit request or upon use, rather than upon opening the context menu.
  • For media and drives without mounted filesystems (where an icon for them is available - eg in the drivemount applet, and "Places -> Computer"), when should detection/mount attempts happen, and how should the GUI respond. How long should a detection result be assumed to be valid, how and when should the context menus change after they have been initially displayed, and should their display be delayed at any time.

    • JohnNilsson (Moved here by TristanWibberley): The issue with context menu waiting for device spin-up might be a non-issue. Isn't all devices read when first presented to the system? When a device finally shows on the desktop it should allready be probed so there shouldn't be a need to probe it further for the purpose of selecting context menu. If the system alters the device the changes should be reflected in the device representation as they occur.

      • TristanWibberley:

      • Floppy drives are known to be present, but the media is not, detection must *certainly* happen there.
      • I don't think all CD drives (if any) notify of the eject button having been pressed, or of the drive tray opening or closing (I think that status can be polled without attempting to spin the disk up, but that doesn't tell you if the media has been changed or not between polls - though I really don't know that).
      • Other removable drives will notify after the change in state has happened, but never before (see the outstanding issue below).
        • This delay between change of state and notification being received is not predictable and a simple delay cannot be put in to filling in the menu items - nor can the menu items really be changed after they're presented, that would be really dangerous. Simply checking status when opening the menu and filling in the end of the menu later mostly solves this. Perhaps, also, the volatile menu items could be greyed out when the device state happens to be found to have changed while the menu is already open, then the user can close the menu and reopen it or something like that - but detection would still have to be done to initially fill the items in, or the menu is horrible to use, with actions that should be immediately available being relegated to "Advanced" (with "Advanced" doing the detection). This isn't only intended to apply to the "Media Present" device icons on the desktop, but should apply to the drivemount applet too. That I can go straight there to open media in the floppy drive is great, but it doesn't work as nicely as it should.

BoF agenda and discussion


DesktopVolumeManagement (last edited 2008-08-06 16:22:15 by localhost)