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 _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
