Date: Tue, 29 Oct 2002 08:32:46 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Laurynas Biveinis <lauras AT softhome DOT net>
cc: Andrew Cottrell <acottrel AT ihug DOT com DOT au>,
   DJGPP Workers <djgpp-workers AT delorie DOT com>
Subject: Re: Findutils 4.1.7 port bugs & fix
In-Reply-To: <8942416321.20021028235207@softhome.net>
Message-ID: <Pine.SUN.3.91.1021029082845.21619N-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Mon, 28 Oct 2002, Laurynas Biveinis wrote:

> 'error waiting for rm' is caused by bitrot in DJGPP port - find 4.1
> upstream uses wait(), 4.1.7 uses waitpid(). DJGPP port used to provide
> its own version of wait() which does DTRT instead of stock lib
> version. I've updated it to provide special waitpid() instead, that
> solves the first problem. Patch (and ChangeLog, in the case you'd
> like to forward it upstream) are at the end.

Yes, perhaps it's high time to submit the patches to the meaintainer, now 
that Findutils seem to be in active development again, after a long 
hybernation.

> The second problem is that find stats directories during their
> traversal and caches their inodes and in the end we receive error that
> inode of some directory has changed.
> 
> Is it possible that our stat() implementation returns different inode
> for the same directory?

This can happen with `fstat', but never with `stat'.  Please try to see 
why does this happen.  In a nutshell, on Windows `stat' stores an 
absolute normalized name of each file it sees, together with its 
(invented) inode, in a special data structure; then each file name it 
gets is first looked up in that data structure, and if found, the same 
inode is returned.  See xstat.c for more details.