[Thunar-dev] Volume manager

[Erik Harrison]

I haven't read the trash spec, but beyond that this looks good.

Frankly, I don't like any solution, but I like the system service
running as root least.


On 6/13/05, Benedikt Meurer <benedikt.meurer at unix-ag.uni-siegen.de> wrote:
> 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
> 
> 
> 
> _______________________________________________
> Thunar-dev mailing list
> Thunar-dev at xfce.org
> http://foo-projects.org/mailman/listinfo/thunar-dev
> 
> 
> 
> 


-- 
"This brings me back to a time where I had no worries. 
All I needed to do was watch Perfect Strangers."
-Erik