[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