Date:	Tue, 8 May 2001 10:08:12 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: ANNOUNCE: Fileutils 4.0 beta 2
In-Reply-To:	<3AF70A71.94C33963@phekda.freeserve.co.uk>
Message-ID:	<Pine.SUN.3.91.1010508100734.3965B-100000@is>
MIME-Version:	1.0
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

On Mon, 7 May 2001, Richard Dawe wrote:

> >      C:\> mkdir a:\foo
> >      C:\> cd a:\
> >      C:\> rm -rf a:/foo
> >      c:/djgpp/bin/ls: a:/foo: Resource busy (EBUSY)
> 
> Eli, it looks like there's been a cut'n'paste error here. Should there be
> some lines between the last two? Or is the last line incorrect?

Yes, it should have said "c:/djgpp/bin/rm: a:/foo: Resource busy (EBUSY)".
It's not a cut'n'paste error, though: I didn't cut'n'paste, I simply
typed this from memory (on my machine, DJGPP is not installed in
c:/djgpp ;-).

> * I had not made 'rm -r' aware of multiple working directories, one per
> drive. If you use a drive specifier, 'rm -r' now saves the current drive's
> and the directory's drive's working directory.

Alternatively, you could change it to chdir to the root of the current
drive before returning from another drive.  Since the root directory
cannot be removed, it is safe to leave the root as the cwd.

I don't know which way is better.  If the changes you did are clean
enough, I think it's an okay solution.

How did the previous port of v3.16 avoid this?

Just for the record: I remember playing a lot with floppies, making
and removing directories on them, back when I worked on porting
Fileutils, probably because I didn't want to risk corrupting my hard
disk.  I found lots of subtle bugs that way.

> > On Windows, `rm' succeeds to remove the directory (evidently because
> > Windows doesn't have problems with removing CWD), but then you have this
> > problem:
> > 
> >      C:\> ls a:
> >      c:/djgpp/bin/ls: a:: No such file or directory (ENOENT)
> 
> This error is a manifestation of the bug in __set_need_fake_dot_dotdot(),
> I think.

No, it's a manifestation of the fact that a: (which is a:/foo) doesn't
exist anymore.  I'm guessing that this error message comes from a call
to `stat' issued by `ls' before it does opendir/readdir.  `ls' `stat's
each file name it sees on the command line before it decides what to
do with them (for a directory, it will readdir it).

Anyway, the fixed ls.exe prints the same message, so obviously
__set_need_fake_dot_dotdot is not involved.

- Raw text -