From:	"Andrew Cottrell" <AndrewCottrell AT swiftdsl DOT com DOT au>
To:	"'Eli Zaretskii'" <eliz AT elta DOT co DOT il>
Cc:	<djgpp-workers AT delorie DOT com>
Subject:	RE: mv bug (filutils? library?)
Date:	Sun, 3 Aug 2003 17:21:11 +1000
Message-ID:	<000001c3598f$d4f02850$0101a8c0@acp42g>
MIME-Version:	1.0
X-Priority:	3 (Normal)
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook, Build 10.0.4510
In-reply-to:	<uk79vs1pr.fsf@elta.co.il>
Importance:	Normal
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2800.1165
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id h737LUd08201
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

Updated info below.

> I don't get it: this sounds like `mv' has rightfully detected 
> that it cannot make this move, and refused to do so, isn't 
> it?  The message "cannot move `junk1' to a subdirectory of 
> itself" seems to suggest that.

The initial call to rename and _rename are okay, but after the return from
_rename() the recusive issue strikes. After the return from _rename() the
directory result is 100% perfect.

> Also, when the problem happened to me (I did see it on XP), 
> what you have after `mv' exits is not just junk1/junk1, but 
> junk1/junk1/junk1/...  etc., ad nauseum.
I didn't want to do a dir /s as then the output scrolls past the command,
but it does occur.
> 
> The error message is also different: I get EPERM after, 
> presumably, the combined length of the file name exceeds the 
> Windows 255-character limit.
I havn't looked at the exact error returned and instead have concentrated on
trying to find where the problem occurs.

> Finally, if `rename' in the library is the culprit, there's a 
> machinery there that's supposed to detect this kind of 
> situation and return a suitable `errno' value.  IIRC, that 
> machinery is based on `_truename', so perhaps `_truename' 
> returns something unexpected in this case.  Please try to 
> step into `rename' and see what happens there.

I am still hunting the exact problem.

I have further traced the problem to the following line in rename(). Before
the call all is okay, but after the recusive junk1/junk1/junk1 exists....
      /* Process all of its siblings.  */
      retval = __file_tree_walk(source, mover);

Andrew

- Raw text -