Date: Tue, 8 May 2001 10:08:12 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Richard Dawe 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: 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, 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.