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: Jim Meyering
Subject: Re: [bug #25294] assertion failure on dangling symlink to //
Date: Mon, 12 Jan 2009 08:46:17 +0100

Eric Blake <address@hidden> wrote:
> 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.

Sure.  reiserfs (3 at least) has no d_type information.

>> 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

Good!

> 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.

All the better.

> 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

Documented semantics of FTS_SLNONE require that fts_statp point
to valid stat data.

> reliable?  Or would the slight semantics changes introduced by treating
> things like ELOOP as FTS_SLNONE instead of FTS_NS be an issue?

It might be.  That change would make at least tests/du/long-sloop
fail in coreutils' test suite.




reply via email to

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