[Mono-dev] DriveInfo reloaded!

[Javier Martín]

Hi all again! I'm back! (did you really think I'd stop bothering you, people?)

I have been thinking about the volume label get/set property in
DriveInfo, which is currently "unimplemented" (i.e. in Linux it gives
the mount point). In Windows we have two handy Win32 calls:
GetVolumeInformation and SetVolumeLabel - the first one also gives us
the FS type, which was lacking in windows. However, in *nix OSes there
is no standard way to get the "volume label", since even the very
concept was FS-specific (though it's curently supported by most FSs
now). In fact, system utilities to get/set the label are either FS
specific (e2fstune, reisefstune...) or just resort to probing for
different partition types and then applying its specific methods
(vol_id).

We have two main choices over the *nix issue: either implement the
probing code ourselves (not too sane, I fear) or query hald through
dbus about it. The HAL+DBUS can even become a truly platform
independent alternative, since AFAIK, there is work being done to port
them to FreeBSD, Solaris and even Windows, though we don't really need
this last port. If I'm right, getting the *nix FS data through HAL
(querying objects with the "volume" capability) would also solve the
problem with FS type identification in Linux: they're currently read
from /proc/mounts, which makes all FUSE filesystems, whatever their
real type, appear as "fuseblk".

If the *nix version is implemented through HAL+DBUS, some new internal
calls would need to be created (since corlib cannot reference an
eventual Mono.Dbus.dll), so I think the Windows version should go
through this icalls too instead of just P/invokes, which would be the
easy way for a win-only solution. In fact, the scheme I currently
contemplate is not unlike how we did the free space implementation
(how are those tests going, by the way?) : every platform goes through
icall, windows calls win32 api and others call a susbstitute in
io-layer.

Potential issues with this implementation: obviously, this won't work
on systems without hald or dbus. Since the #else case is too
complicated (tons of partition probing code, possibly requiring
privilege elevation), I'd rather just throw a NotSupportedException on
those systems, indicating that dbus+hald support is required. Also, if
dbus is not used anywhere else on libmono, the main
configure.ac/Makefile.am/config.h.in/whatever files would have to be
modified in order to search for the dbus-glib binding, its shared
library, etc. Not exactly an easy feat, but I think it's doable and
worth the effort. In my opinion, dbus should _not_ be a required
component (i.e. stopping configure/compile if not found), because the
provided functionality is not critical for 99% of apps.

Well, that was it. Any ideas? pointers? advices? flames? vetos? (I
hope none of these last two, but one has to be prepared). Any opinion
will be welcome.

Habbit