[Top][All Lists]
[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.