[Mono-dev] DriveInfo implementation
robertj at gmx.net
Wed Dec 5 09:53:22 EST 2007
Javier Martín wrote:
> 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...
I-calls don't need marshaling. Maybe some char* to MonoString*
conversions, but it's trivial to do.
> 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.
Well, that's the way how the I/O subsystem has been implemented:
Write unit test cases on Windows and implement the missing I/O
> 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,
On MS.NET, the 3 related DiskInfo properties always correspond
to what GetDiskFreeSpaceEx returns, even with quotas on,
so I guess their docs are wrong.
More information about the Mono-devel-list