bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #25294] assertion failure on dangling symlink to //


From: Eric Blake
Subject: Re: [bug #25294] assertion failure on dangling symlink to //
Date: Sun, 11 Jan 2009 15:38:44 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Jim Meyering on 1/11/2009 3:06 PM:
> I tried your "find -L dir-containing-loop" example
> on ext3, tmpfs, and xfs, and it appears d_type is always DT_LNK,

Is there any file system on Linux where you can always get DT_UNKNOWN?  If
not, I'll keep playing with it on the cygwin side of things.

> so what do you think about changing the test to e.g.,
> 
>                       if (FAILED_STAT_ERRNO_MAY_INDICATE_SYMLINK (errno)
> 
> Where the macro is defined like this:
> 
> #ifdef ENOSHARE
> # define FAILED_STAT_ERRNO_MAY_INDICATE_SYMLINK(Errno) \
>     ((Errno) == ENOENT || (Errno) == ENOSHARE)
> #else
> # define FAILED_STAT_ERRNO_MAY_INDICATE_SYMLINK(Errno) ((Errno) == ENOENT)
> #endif

I already did something like that patch that on my copy of findutils on
cygwin; the //noshare bug went away, but the assertion failure on a loop
still remains.  But this particular patch seems like overkill, now that
cygwin no longer returns ENOSHARE (as of this morning, the developers
agreed that ENOSHARE doesn't make sense any more; it predates the time
when cygwin had support for //server syntax):

http://cygwin.com/ml/cygwin/2009-01/msg00284.html
http://cygwin.com/ml/cygwin-cvs/2009-q1/msg00014.html

> 
> I checked a few Linux/GNU systems and found no ENOSHARE definition.
> I.e,. how about this patch?

Let's not bother with it.  Cygwin 1.5.x is immune (no d_type support), and
since cygwin 1.7.0 is not yet a stable release, and has fixed the ENOSHARE
issue already, there are no stable cygwin releases that need the workaround.

On the other hand, what did you think of my idea of using readlink()
instead of lstat() to determine if a file is a symlink after stat() fails
(and when d_type is unavailable or DT_UNKNOWN)?  Is that any more
reliable?  Or would the slight semantics changes introduced by treating
things like ELOOP as FTS_SLNONE instead of FTS_NS be an issue?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklqdPQACgkQ84KuGfSFAYCN/wCeIlmEdlflfgHBpCTbOVLefdeY
24gAn2RP4dpeP/cY96/0FNenJBmlGlwe
=A4BQ
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]