[Thunar-dev] Volume manager

[Benedikt Meurer]

I've been thinking about the volume manager lately, and I have
experimented with a possible implementation for BSD derived systems,
which includes the basic functionality, that should also be possible
with Linux and other Unices.

Attached to this mail is the general interface and the BSD specific
implementation (well, more of a prototype, but it's working). There's no
new tarball, as it currently does not compile on anything except
FreeBSD/NetBSD, nor does it do anything amazingly useful. For those who
think that screenshots are necessary, here's a simple screenshot showing
the favourites pane with the volume manager integration:

   http://xfce.org/~benny/tmp/thunar-volume-manager-20050613.png

The volumes "cd0" and "cd1" are automatically detected and won't be
shown until the kernel says that a disc is present (which is the case here).

Now the design: To keep things simple, I tried to come up with a minimal
set of requirements for 1.0:

http://xfce.org/~benny/tmp/ThunarVFS-volume-manager-requirements-20050613.png

The trash system requires the volume manager to be able to determine the
trash directory for a given file (see the trash spec for details).

The other requirements are for the favourites/tree panes, in order to be
able to display removable devices and mount/umount them. The data
provided for every volume should be atleast:

   1) the current status (medium present, mounted, maybe more...)
   2) the icon (looked up automatically in an icon theme)
   3) the kind of device
   4) the name of the volume (usually the device name, maybe even the
label extracted from the media, e.g. the CD label, but that's not
included in the prototype so far)

Atleast 1) and 3) are highly system dependent, as well as the code
required to query the list of volumes (just look at the fstab code I
initially wrote for xffm some time ago, and you'll see that this is
really tricky). So, every system family will get its own implementation,
and access happens through the general interface.

So far, so good. The problem with this approach is, that some of the
operations require superuser permissions. For example, on FreeBSD (and
on most other unix-like systems I know of), the device nodes for the
removable devices are usually not readable by the average user in a
standard installation, but this is required to query the medium status
(see the thunar_vfs_volume_bsd_update method) of a CD-ROM drive.

And so, another possible solution comes in mind: The volume manager
could be implemented as a separate D-BUS service and thunar-vfs will
include only wrapper classes that simply forward all requests to the
service (with appropriate fallbacks if the service isn't running). The
service itself would run with superuser permissions and would thereby
provide all users with the ability to query device status and
mount/umount volumes (of course, there'd be a way for a system
administrator to configure the exact permissions). Unfortunately, this
solution isn't optimal as well: If for some reason the volume manager
service isn't running (e.g. sysadmin does not want another service, or
for whatever other lame reason), the trash system won't work properly
(or we'd need to replicate some of the functionality of the volume
manager service in thunar-vfs to get atleast a working trash system,
even if the service is down, which is of course a bad idea). And of
course, having the volume manager as a system service, running with
superuser permissions, requires careful (and regular) auditing for
possible security problems, etc., which is certainly not what we want.

  From my point of view, the way to go for 1.0, is definetly having
everything in the library, and re-evaluating the issue for 2.0 again.
This way, if a user wants to be able to effectively use the volume
manager in Thunar for mounting/umounting volumes, he'd need to adjust
the permissions for the appropriate device files in /etc/devfs.conf (or
wherever the devfs configuration resides on his system) first. Most home
users should have done that already anyways, because else they wouldn't
be able to listen to audio cds, etc. either. For the mounting and
umounting, we'd need to rely on the operating systems handling for user
mounts ("user" option on Linux, vfs.usermounts on BSD and some Unices).
Systems that don't fullfil these basic requirements or don't support a
way for users to perform these actions won't be supported in the first
version (that is, not supported by the volume manager, the other parts
of Thunar will work of course).

So, I'd like everybody to have a look at the requirements and check if I
missed some important point (of course, other UI modules can also use
the volume manager if required, for example, the location buttons module
will use it in order to display removable volumes as roots, etc.). If we
can all agree here, I'll refine the formal description and improve the
interface and the BSD implementation (possibly adjusting oddities in the
interface as required). Once that is done, the volume manager interface
will be frozen (except for critical changes) and implementations for
other operating systems can be done. So if somebody feels like writing
some code for Thunar, here's your chance. ;-)

Some notes about the Linux implementation: Since Linux nearly implements
the SysV interface here, the Linux backend should probably be renamed to
sysv and whoever implements it should take care that the code also works
on SysV derivates (there should be only minimal differences, check the
xffm fstab plugin for sample code). The backend should work on all Linux
systems, independent of any special services or kernel features (esp.
Linux 2.4 must be supported properly).

Later, once the general linux/sysv backend is done and working, a HAL
backend could be implemented as well, but that's optional and not really
required, as the general backend will work for all Linux systems. It'd
would be nice from a marketing point to have an optional HAL backend, tho.

That's all for the day.

greets,
Benedikt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: thunar-vfs-volume-manager.tar.bz2
Type: application/octet-stream
Size: 6773 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/thunar-dev/attachments/20050614/0e0dc624/attachment.obj>