[Mono-dev] DriveInfo implementation

[Javier Martín]

Things are looking up from the Linux world. In fact, a preliminary
(working) implementation is complete. However, I have one main concern
to which I have found no answer in MSDN: do DriveInfo instances provide
live information or just read it once when they are initialised? 

Intrigued be not, my friends, for the answer will come tomorrow when I
reboot into Windows and observe the wild behaviour of M$'s .NET. Right
now my implementation opts for the second, easier choice, but I believe
the first is way saner for client classes.

Another possible problem with my modifications is that they could
require building corlib.dll with a reference to Mono.Posix.dll. It's not
the fact that it can lead to chicken-and-egg problems, I'm sure Mono's
build systems can handle that, but the thing that bugs me is that, if
nothing else in corlib uses Mono.Posix apart from this new code, the
reference and everything using it should be inside an #if block so that
a corlib build for Windows does not uselessly (though harmlessly, I
hope) reference Mono.Posix.

Other changes I've made:
	1) added a big comment near the Env.Platform detection hack explaining
the tearful history
	2) renamed a variable in UnixGetDrives().

Further changes I'd wish: 
	1) beefing up the Unix* methods so that we support BSD at the very
least. The statvfs syscall is POSIX and thus should be supported on
them, by I can't seem to find anything standard similar to /proc/mounts
and/or getmntent(3). However, I'm sure there has to be something not
unlike it. Currently I can't help on this one because I don't have any
BSD installed.
	2) some cleanup. There are too many "Console.WriteLine"s in this file,
which is cool for debugging, but they _are_ reaching the end user, which
is quite uncool for a production runtime that will soon reach version
1.2.6.
	3) tidying of the LinuxGetDrives method. Its current implementation is
good, but it _looks_ too hackish. I've been thinking on how to improve
it. Splitting the line in space-separated fields would be
memory-wasteful, but cleaner. Dunno, maybe a loop would do... o_O
	4) a rationale on why cdrom, ram and "unknown" FSs had their free size
forced to 0. CDs I could understand (unless packet writing is in
service, but that's another story), but ram? Both Windows ramdisks and
tmpfs in Linux can indeed be writable. So I've commented the relevant
lines, keeping them in the file.

And... here is the current implementation, people. The only file
modified was DriveInfo.cs. Everything should compile fine, or at list so
it did for me. And, unlike my CS patch, I think I didn't break anything
- mainly because there was nearly nothing to break ^^


Habbit




-------------- next part --------------
A non-text attachment was scrubbed...
Name: DriveInfo.diff
Type: text/x-patch
Size: 4261 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071205/9defde9c/attachment.bin