[Mono-dev] DriveInfo implementation

[Javier Martín]

Hi again,

> Hello Javier,
> 
> > 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.
> 
> Ah, but we should not be adding a dependency to Mono.Posix to mscorlib,
> that is a no-go.
> 
> Robert Jordan's suggestion seems like the right one: this code should
> likely be implemented in the io-layer.
> 

So I thought: the platform differences can be accounted for with some C
support code, while the managed code can just do an internal call and
receive a nice structure with the right fields. However, it's a pity
that the code will need to cope with all the marshaling that Mono.Posix
automagically did...

By the way, I did that reboot and found out that MS's implementation
does tap into live data for every call to the drive space properties, so
I'd have had to change the implementation nevertheless.

Before starting, however, I'd like to gather opinions on how this should
be accomplished. From the look of the current io-layer code and Robert's
suggestions, I'd probably have to find a Win32 API that does the job,
then implement a *nix substitute for it with the same signature in
io-layer using whatever posix calls I feel like. This is not as clean as
I would have wanted it to be, but still good enough. The "bad" thing is
that I'd have to create a working Windows implementation first and only
then reimplement it through io-layer. The other way around is using
statvfs and then creating a substitute for it in io-layer. Not
impossible, but until now never done in mono AFAIK.

I'm currently split between two ways to do the trick with Win32 calls:
the first, easy way GetDiskFreeSpaceEx, which does 99% of the required
work. The only way it could go awry would be if space quotas are in
effect. The second, tough way is DeviceIoControl (ioctl for friends)
with IOCTL_DISK_GET_LENGTH_INFO as the argument. More complicated and
error-prone, but will always report total figures. What do you think,
people?


Habbit