From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <10110151436.AA14048@clio.rice.edu> Subject: Re: W2K/XP fncase To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii) Date: Mon, 15 Oct 2001 09:36:46 -0500 (CDT) Cc: djgpp-workers AT delorie DOT com In-Reply-To: from "Eli Zaretskii" at Oct 15, 2001 10:46:00 AM X-Mailer: ELM [version 2.5 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 > A space is not a valid character on DOS; the files that you see were > created by programs which zap the directory entry via direct disk > access on the sector level. The technical reference I have says that space is invalid - but also says this is due to file name syntax reasons (the same reason that + was illegal in DOS). In reality, you can create file names with spaces and open them without problems. Boot a DOS 5.0 diskette and use DJGPP with a filename with a space. It creates it without problems. If you set lfn=n you can create files with spaces in them without problems also. Microsoft itself used names with spaces in them for extended attributes before LFN API (anyone remember EA DATA. SF?) > As your testing indicates, the amount of such files is miniscule, and > they are usually hidden, so won't show up in most programs. I think > we can safely disregard them. As rare as they are, and the purpose of the code (to determine if we should downcase the name or add a few bytes of size to a directory entry) it doesn't matter much either way. > What about blanks? We shouldn't downcase file names with blanks, I > think. I don't care either way. They can be real DOS files. Under Win95 if you create the file with a space with lfn=n, no extra entry. > [Making fncase=y default] would be low risk on W2K/XP, because those > systems didn't exist until now. But all the configuration/build tools have been tuned for fncase=n systems - so I believe all platforms should have the same defaults. > > The test program compares the behavior to the strcmp(_lfn_gen_...) combo. > > On my Win95 system it found one difference, a DOS game copy protection > > file which contains a space. > > In my case, it tried more than 85,000 files and found no differences. > > Note that, as written, the program will not try hidden files because > `glob' ignores them when expanding wildcards. Yes it's not an extensive test (there are directory names that aren't tested) and there may be ways in libc to send things not yet tested, but I thought it was worth "code is worth a 1000 words" to give a prototype - and a little confidence this was not going to break everything in sight. > I suggest to have this return an int instead [of char]. Since it's a boolean (0/1) I chose the smallest native type to represent it, but int would be fine too. (char just saves a few bytes loading some constants, so smaller code). > > if(*s == '.') /* starting period invalid */ > > return 0; > This will do the wrong thing with "." and ".." (if the function is to > be used for something other than just the decision on whether to > downcase; the function's name suggests that it's supposed to tell > whether the argument is a valid DOS file name). I thought about that at the time. I can allow those, or we can rename the function. The current strcmp(_lfn_gen... fails on . and .. also. It's trivial either way. > > else if (c == '+' || c == ',' || c == ';' || > > c == '=' || c == '[' || c == ']') > > I think this should include a blank. Whatever you decide after knowing ' ' is a valid character in names when lfn = n ! Try it yourself ... open("AAA AAA", ... > > I don't see any way to fix [_lfn_gen_short_fname for W2K/XP] other than: > > 1) Document it's trash and advise no one to use it, or > > 2) Insert emulation code if os=2K/XP inside it. > > We should at least document this. I think we should also file a bug > report with Microsoft; it's a disgrace for their QA to let such bugs > into the open. Yes, but the question remains - do we leave the current code in the library, or update it with DH=1 (which works for some file names), or just document it's bad, or insert emulation code?