Mail Archives: djgpp-workers/2001/10/15/04:50:50
On Sun, 14 Oct 2001, Charles Sandmann wrote:
> So the
> goal of the calling the _lfn_gen_short_name interrupt is to determine
> if the name is a legal 8.3 dos name in all upper case.
More accurately, the goal is to determine whether the file has (or
would have, when created) an LFN entry in the directory. Using
function 71A8h is an approximation to that goal. But the distinction
is probably not important for most practical purposes.
> Are you aware that _lfn_gen_short_name does *NOT* do this properly
> even on W9x?
No.
> I can give examples of names I create under regular DOS
> or with LFN=n, that _lfn_gen_short_name returns a different value
> than what is stored on the file system. In particular, space is a
> valid character under DOS, and so are many other 8 bit characters.
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. 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.
> So we don't lower case any files which contain spaces (and many that
> contain 8 bit chars) but legitimately we should. Sure, the impact
> here is negligible, it does the right thing 99.9% of the time. But
> we can't point to the interrupt on W9x and say it's doing the right
> thing either.
It was the best thing I could think of at the time. I didn't know
then what was the exact algorithm used by Windows to generate the
short names; as a matter of fact, I didn't even have good access to a
Windows 9X machine, so I wrote the code half-blind.
But this isn't important now, after it has been working so well for 2
years.
> Thus my argument to replace it with something.
It's not an argument important enough, IMHO: we shouldn't be fixing
what ain't broken. What _is_ important is that the current code
doesn't work at all on W2K and XP. *That* is a good reason to change
the existing code.
> > Actually, on Windows 9X, it's very easy to predict whether the file
> > will be downcased or not; in that respect, _lfn_gen_short_fname does
> > its job quite well on W9X. It's W2K and XP that introduced the
> > problem.
>
> I mean from a user point of view. I can display two names, identical
> except for a difference in one 8-bit character. One will convert, one won't.
For 8-bit characters, I can imagine that you will see all kinds of
weird things. Their handling in DOS and Windows is very messy and
inconsistent. Since we don't have any real support for such file
names, I wouldn't be bothered about them. The fact remains that I
didn't see any complaints about file letter-case behavior that were
related to 8-bit characters.
> I never intended to always downcase on DOS. I just
> plan to say if lfn=n and "fncase flag" then go directly to downcase, don't
> bother generating any names or logic. If there are cases that some DOS
> returns mixed case and we want to keep it, then we can process it's names
> too using the same algorithm.
Sorry, I don't understand: what is this ``fncase flag''?
> Which does not call any buggy Windows interrupts. It would not consider
> names with lower case or +,;=[] as DOS83, or any with multiple periods, or
> leading periods.
What about blanks? We shouldn't downcase file names with blanks, I
think.
> Length must be <=8 chars before a period or 12 chars total.
And the extension must be <= 3 characters (cf. foo.barbaz).
> > > If there is no way, then maybe fncase=y should be default if lfn is
> > > enabled for all platforms.
> >
> > You mean, including Windows 9X? We could consider making this change
> > now, but how do we check it won't get users in trouble? Windows 9X
> > and ME are still the most popular systems.
>
> Your original proposal was to just always force Win2K and XP into
> fncase=y, so I took this proposal to mean it was low risk.
It would be low risk on W2K/XP, because those systems didn't exist
until now.
> > I'm not comfortable because I'm afraid to break things. The
> > letter-case handling is very fragile, so the more localized the change
> > and more predictable its effect, the less risk we run. Changes that
> > touch all platforms and modify the resulting string (the one returned
> > by _lfn_gen_short_fname) in non-trivial ways is something whose
> > effects I have no way of knowing in advance.
>
> I think I understand the 7 places we currently use it enough to believe
> this is a relatively low risk change.
We clearly disagree on this. I don't know how to resolve this
disagreement. I don't even know if I'm right; maybe I'm just haunted
by the shadow of a dwarf. In any case, I'd love a solution that would
be much safer on Windows 9X, if that's possible.
> I have no idea if any external code uses _lfn_gen_short_name for
> anything useful - if so they will be badly broken today on W2K/XP
> until fixed.
I don't see any problem in that; we should simply document that the
underlying system call is botched on those systems.
- Raw text -