Date: Sun, 23 Sep 2001 21:10:43 +0300 From: "Eli Zaretskii" Sender: halo1 AT ZAHAV DOT NET DOT IL To: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <1659-Sun23Sep2001211042+0300-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9 CC: djgpp-workers AT delorie DOT com In-reply-to: <10109231606.AA13897@clio.rice.edu> (sandmann@clio.rice.edu) Subject: Re: rm -rf disaster bug [was Re: gcc-3.01 seems unstable] References: <10109231606 DOT AA13897 AT clio DOT rice DOT edu> 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 > From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) > Date: Sun, 23 Sep 2001 11:06:14 -0500 (CDT) > > > Eli said this: > > "It's all expected: legacy DOS calls are limited to 64 characters in > > the directory part of a file name, and to 8 levels of subdirectories > > (which you exceeded). > > If this is the case the code should have an assert in it and bail if > there are more than 64 chars. The problem is: where do you put these asserts? The best place is _put_path, but the test needs to look at _USE_LFN, and you cannot issue system calls from _put_path, for obvious reasons. That leaves us with lots of possible places, and a potential for lots of slow-down. FWIW, on plain DOS, the too-long names never cause the root to be substituted for the actual file name: they simply fail, but never do any harm of the kind that was reported here. Also, until we understand the problem reported by Wojciech, I don't think we should cry wolf. Who knows, perhaps the real problem has nothing to do with 8-level directory limit. > > Now to the problem: I've tried to keep up with the Win2k discussions. From > > what I remember some file handling is done with SFNs, because Win2k's LFN > > handling is a bit broken. So perhaps the changes expose the same problems > > I experienced when running the Fileutils tests with LFN=n on Windows '98 > > SE? > > We are only doing this for open() related handles. Right; and so I don't think the problem reported by Wojciech is relevant to these, since it has to do with the length of file names, not with file handles. Removing files is never about file handles.