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
Content-Type: text/plain;
	charset="us-ascii"
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
Content-Transfer-Encoding: 8bit
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
Precedence: bulk

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