Mail Archives: djgpp-workers/2001/10/15/10:41:40
> 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?
- Raw text -