[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