[Mono-list] Mono.Unix.Native.Syscall.(l)stat weirdness

[Jonathan Pryor]

On Wed, 2006-02-22 at 19:52 +0100, László Monda wrote:
> On Fri, 2006-02-17 at 06:28 -0500, Jonathan Pryor wrote:
> > On Fri, 2006-02-17 at 00:36 +0100, László Monda wrote:
> > > UnixFileSystemInfo seems to be a well-designed abstraction on top of the
> > > Unix VFS API, but I'll stick with syscalls, because I don't like
> > > UnixFileSystemInfo's exception policy.
> > 
> > What don't you like about its exception policy?
> 
> It was something to do with dangling links.  If I remember correctly,
> UnixFileSystemInfo throwed an exception on dangling links.  I wanted to
> subclass this class, but this policy made it unconvenient for me.  Of
> course, my scenario is rather unusual, because I'm writing a file
> manager application and the File class is a critical part of it.

UnixFileSystemInfo's exception policy is to throw an exception if the
file doesn't exist.  You were probably using the UnixFileInfo subclass,
which uses Syscall.stat, which would generate an exception when trying
to access the UnixFileSystemInfo members.

If you need to care about potentially dangling symlinks,
UnixSymbolicLinkInfo would be your friend, as it uses Syscall.lstat to
provide information, thus no exceptions would be generated when
accessing the UnixFileSystemInfo members.  Instead, you might get an
exception when reading UnixSymbolicLinkInfo.Contents, which tries to
create a UnixFileSystemInfo object on the dangling symlink target.

One issue that I've just found is that for dangling symlinks HasContents
will return true while Contents will generate a FileNotFoundException
exception.  This is obviously bad (as there's no way to avoid the
exception), and I will fix this.

(Then, to be fully confusing, if you create a UnixSymbolicLinkInfo over
a regular file, Contents will return null instead of generating an
exception.  Yay consistency!  At least HasContents returns false in this
case...)

I need to make a public UnixFileSystemInfo.CreateInfo() method which
looks at an existing file and creates a UnixFileInfo, UnixDirectoryInfo,
or UnixSymbolicLinkInfo instance as appropriate for the specified file.

> I probably had some other minor issues with UnixFileSystemInfo, but the
> above behaviour was the showstopper.
> 
> In the end, I implemented my own File class.  You may want to take a
> look at it:
> 
> http://cvs.sourceforge.net/viewcvs.py/ulc/uc/File.cs?view=markup

FYI, your SymbolicPermissions property could be replaced with
Mono.Unix.Native.NativeConvert.ToUnixPermissionString().

 - Jon