This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bumping findutils?


On Apr 11 06:35, Eric Blake wrote:
> Based on the number of reports to the main list about cygwin-1.5.19
> interaction with bad samba inodes, and with find 4.2.27 reacting loudly
> while find 4.3.0 tends to do better (but not perfectly), I am considering
> bumping 4.3.0 to current.  I'm also unsure why some people have claimed
> that oldfind 4.3.0 works when find 4.2.27 does not, since they use the
> same algorithm and compiled against the same cygwin version.
> 
> One benefit of making 4.3.0 current would be one less question to ask
> people when they report that "find isn't working" without attaching
> cygcheck output.  On the other hand, 4.3.0 is marked alpha quality by the
> upstream maintainer (although I haven't encountered any serious problems
> with it).
> 
> One other point:  both 4.2.27-1 and 4.3.0-1 depend on cygwin 1.5.19,
> because they use getline().  To date, I have left 4.2.25-2 as the previous
> version since that way someone can use setup.exe to select cygwin 1.5.18
> and an accompanying version of findutils that still works.  If I made
> 4.3.0 current, should I leave 4.2.25 as previous, so that this scenario
> still works?  Or should I bite the bullet and leave 4.2.27 as previous, so
> that people can still get the latest stable upstream version, but can no
> longer backrev findutils when they backrev cygwin?
> 
> Or is 1.5.20 close enough on the horizon that I should just wait for it to
> come out?  At that point I will probably release as current 4.3.0-2 that
> uses inodes (4.3.0-1 was compiled in the short window of time when d_ino
> did not exist), and would feel fine about leaving 4.2.27 as previous since
> cygwin 1.5.19 would be the oldest version that setup.exe would then support.

I can't tell how long it takes until we release 1.5.20, but in the
meantime I'm wondering if we should just give up and revert to using
fake inode numbers on Samba shares.  I don't see any way to distinguish
between Samba versions with good and with bad inodes, except the inode
number generation would be unambiguously different.  I'm still hoping
that older Samba versions set the upper 64 bit of the file id to 0,
that would do it.

Anyway, I don't think that the find version should be changed because
Cygwin has problems with Samba inode numbers, but eventually it's your
call.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]