[Mono-dev] DriveInfo implementation

[Javier Martín]

Hi again,

2007/12/4, Miguel de Icaza <miguel at novell.com>:
> Hello,
>
> > I would like to help in the implementation of the System.IO.DriveInfo
> > class, which as of now is semi-functional in Linux and little more
> > than a stub in Windows. However, after thinking a bit about it, I've
> > come to the conclusion that the methods that discover the volumes in
> > the system (*GetDrives) require P/Invoke at the very least (windows),
> > and possibly even unmanaged code (linux).
>
> Correct, for Windows we should use P/Invokes.
>
> For Linux, the current "trivial" implementation is enough, a more
> complete implementation probably should talk with DBus to Hal, but am
> unsure about that.

It's not enough for me, as I need to get the free space in the FS.
That's how I found out that this class is incomplete, and, after
seeing that it had been so for a long time, decided to volunteer on
it.

>
> For Unix, a full solution probably needs to use Mono.Posix to get the
> file system information (notice that information about actual devices is
> hard to obtain in Linux, unless we use something like Hal).

Hmm... You should be right about most unices, but I don't see the
reason info would be hard to obtain in Linux - AFAIK it supports the
statvfs(2) POSIX syscall, which df uses to get the FS data. I think it
should provide most, if not all of the info needed. Besides, it's
already in Mono.Posix.Native, so the code changes would probably not
be too invasive.

There _could_ be problems with esoteric (and not so strange) unices,
as the massive display of #ifdefs in the GNU coreutils fsusage.[hc]
shows, but, most probably it shouldn't be so tough for just Linux and
BSD.

>
> > The point of this message is asking for directions and rules on this
> > matter. Is unmanaged code (at all) allowed? Can I create a portable
> > "interface" (not necessarily a .NET interface) and then a separated,
> > system-dependant implementation? How are those platform-dependant
> > switches managed in the Mono autoconf files? Etcetera.
>
> I believe that for the Windows case, you could get away with P/Invoke,
> we have used glue in the past, see the mono/support directory, it
> contains plenty of portability glue.

I will look further into it, thanks for the $address. However, even
when I can use P/Invoke, shouldn't it be separated from the
platform-independent code by an interface?

>
> > I would appreciate any pointers on the matter.
> >
> > Habbit
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>