Quoting the Bicentennial Man, "one is glad to be of service" ^^ However, there are some chilling news: in these last weeks, I've been gathering information on the DriveInfo spec and MS's implementation, comparing them to what we have in Mono. The results are not exactly cheering.
MS's implementation seems to save just the path entered when creating the instance. Only in the constructor is the path checked against the mounted volume list and rejected if there is no such volume. However, after that all properties are dynamic: if the volume is unmounted all throw an IOEx, all save DriveType which returns NotRootDirectory (whatever, I don't remember the enum tags right now). Also, if the path passed to the constructor points to a directory within a volume, it can be either a mount point (NTFS junction), a symlink (NTFS reparse point) or just a standard directory. I still have to check the two first, but in the latter, MS's implementation gets you the drive information for the correspondant volume. The current Mono implementation does nothing of this. First, most of these properties have only stub implementations, which rely on arcane methods (parsing /proc/mounts in Linux is just an example). Also, the drive type and format are determined at construction time, so if a volume is unmounted the DriveInfo instance would show inconsistent behaviour (the currently static properties would keep referring to the unmounted drive, while the dynamic ones would either raise exceptions or return values for another volume). In Windows, these properties don't pose a programming challenge - there are easy-fitting Win32 API calls for most of them, and in fact I've already got a preliminary implementation of (g) DriveFormat and (g/s) Label. I'm currently working on (g) DriveType, which is crucial for sane behaviour of the whole class. In Linux, however (or other unices), things don't look so up. The current approach of parsing /proc/mounts is a bit of a hack: works, and provides information about all mounted volumes whatever its options (real mount, bind, loopdev), but if the class properties become dynamic, we could find DriveInfo parsing /proc/mounts once per call. Besides, FUSE devices (NTFS volumes mainly, though also many other FSs and pseudo-FSs) are reported as "fuse" or "fuseblk". I once heard of a submitted kernel patch to make them be reported as "fuse.sshfs" or "fuseblk.ntfs-3g", but either it's going to be included in 2.6.24 or it's "lost in translation". Finally, this way fits only Linux, but (I think) neither the BSDs nor commercial Unices. We probably want a portable implementation rather than 5 different ones. Even if there _are_ so many different versions of this platform-dependent code, my opinion is that they should be "hidden" in io_layer, not in mscorlib. I thought of using the getmntent function family, together with the already used statvfs, but I don't think they provide enough information. I also dipped a toe in the HALd world (over DBUS). The information it provides is very good and complete, and could be even be ported to other Unices apart from Linux, but it only works with physical devices: loopdevs and bindings are not reported through it, which is bad, because some users depend on loopmounted volumes (WUBI, cryptoloop, etc). I admit I'm completely lost on this *nix issue, as this area is not exactly standardised, even on Linux. Also, if I make any further changes to the Windows version, it'll behave quite differently in Linux (dynamic vs. saved properties mainly), which I think is not exactly optimal. Any ideas? Habbit 2007/12/20, Miguel de Icaza <[EMAIL PROTECTED]>: > Hey Javier, > > Excellent work! I know that it has been a long process from the > original simple contribution, but am looking forward to it ;-) > > Miguel. > > On Thu, 2007-12-06 at 14:33 +0100, Javier Martín wrote: > > Status update: I'm currently at step 4, i.e. the Windows version has > > been implemented and everything seems fine, sane and consistent. I had > > to implement the WindowsGetDrives method too in order to make the > > class even usable, but it's a bit of a stub based on > > Environment.GetLogicalDrives and does not detect the filesystem type - > > that should be trivial with the Win32 GetVolumeInformation call, but > > it's secondary and for later: I don't want to add two new internal > > calls on a single patch. > > > > I'm now going for lauch. If noone reports breakage in a few hours, > > I'll start with the POSIX port, probably adding two files "volume.h" > > and "volume.c" to io-layer, since I don't think the new functions fit > > anywhere else. > > > > I have done my best to create solid, consistent code and to avoid > > corrupting the namespace, but if anything can be improved, I'm > > positively waiting for feedback. All my code was compiled with MSVC > > 8.0 (a gcc cygwin build proved frustratingly impossible because of a > > Makefile error), so, even if I tried avoiding compiler dialectisms, I > > could have introduced some. > > > > This patch has two diff files: icalls.diff (to be applied at > > /mono/metadata) and DriveInfo.diff (at mcs/class/corlib/System.IO). > > Also, I noticed an small typo at the declaration of the Exp function > > in mcs/class/corlib/System.PAL/IOperatingSystem.cs (dobule instead of > > double) which prevented corlib from compiling at first. > > > > Habbit > > > > 2007/12/5, Javier Martín <[EMAIL PROTECTED]>: > > > Ok, this last nut of wisdom from Robert has really fueled me up. It's > > > quite nice to be back from class and find such good news lying on my > > > mailbox. So, I'm starting with the Windows version first. Since this > > > will be the first time I delve into the depths of the runtime's > > > support code, I've written a small checklist with what I'll do where > > > so that any accidental receiver of this list can spot the probable > > > mistakes that my usually astounding lack of judgment is certain to > > > cause x_x > > > > > > --ON WINDOWS-- > > > 1.- DriveInfo.cs - create a "external" method with the appropiate > > > MethodImplAttribute flagging it as an internal call. > > > 2.- icall-def.h - define the new internal call, possibly MONOIO_34, > > > and route it to a new function > > > 3.- icall.c - implement the said function, calling only ANSI C and > > > Win32 APIs. Be careful not to dereference NULLs, corrupt memory, etc, > > > since mommy GC & daddy runtime are not here to help > > > 4.- build and check everything is sane. Compare to M$'s results > > > --ON LINUX-- > > > 5.- some file in io-layer, possibly io.c - implement POSIX-based > > > substitutes to the missing Win32 functions/structs/etc I've used > > > 6.- $thatLastFile.h - expose the Win32 prototypes I've used > > > 7.- build and check everything is sane. Compare to both mono-win and > > > MS-win results > > > --HAPPY ENDING-- > > > > > > Seems easy at first, but I suppose it's neither a piece-of-cake nor an > > > impossible mission. Well, tomorrow is a holiday here in Spain, so I > > > can hack the whole day. > > > > > > Habbit > > > > _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
