[Mono-dev] Replacement for Mono.Unix.UnixFile.TryReadLink
    Jonathan Pryor 
    jonpryor at vt.edu
       
    Wed Jan 11 19:12:18 EST 2006
    
    
  
On Wed, 2006-01-11 at 17:25 +0100, Paolo Molaro wrote:
> On 01/11/06 Jonathan Pryor wrote:
> > > The behaviour of TryReadLink and
> > > UnixSymbolicLinkInfo.ContentsPath seems to be the same. Wanted to
> > > counter check if this is indeed the case.
> > 
> > Those aren't direct equivalents.  UnixSymbolicLinkInfo.ContentsPath is
> > equivalent to UnixFile.ReadLink() -- it will throw an exception if there
> > was an error reading the link.  UnixFile.TryReadLink() can be simulated:
> > 
> >         // 1.1.12 Code:
> >         string target = UnixFile.TryReadLink ("sym-link");
> >         
> >         // 1.1.13 Code:
> >         UnixSymbolicLinkInfo symlink = new UnixSymbolicLinkInfo ("sym-link");
> >         string target = symlink.HasContents ? symlink.ContentsPath : null;
> 
> Why is the first method obsoleted, though? It's way clearer and likely
> faster, too.
Because most of the UnixFile methods were forwards to UnixFileInfo
members, so I removed it in the interest of simplification &
documentation.
See also:
http://lists.ximian.com/pipermail/mono-devel-list/2005-October/015441.html
I also doubt that it's significantly faster.  The UnixSymbolicLinkInfo
creation implies a stat(2) call that TryReadLink() avoids, but
TryReadLink() didn't know how large a buffer readlink(2) required (which
is stat.st_size), so it had to guess (and it guessed wrongly -- if the
symlink was > 512 characters TryReadLink() would return null).
 - Jon
    
    
More information about the Mono-devel-list
mailing list