Mail Archives: djgpp-workers/1996/07/29/10:42:25
> 1) The LFN cannot be computed once at program start-up, because a
> program can say ``putenv ("LFN=n")'' and expect this to take effect
I disagree. I think if you toggle the to-be-defined-and-documented
memory flag, you could change the behavior, or you set it in crt0 flags,
but checking the environment outside the crt1 initialization for changes
is an unneeded complication. Keep it simple.
> 2) The current `_use_lfn' calls function 0x7174 (get current
> directory). Why not 0x71A0 (get volume information)? The latter seems
> to return the LFN flag explicitly, and the docs seem to suggest it only
> hits the disk the first time it's called.
I wrote this in W95 beta days, and 71a0 was broken then. Since the
get CWD call never hit the disk, it seemed like the simplest, easy choice.
> 3) It seems that the LFN can be supported for some drives, but not
> for others (otherwise, why does 71A0 ask for the drive?). Our code
> assumes that the support is the same for all drives, and so queries the
> filesystem about the current drive. Is this right? What about
> NFS-mounted disks under Win95--do they always support the LFN API?
If the LFN API is supported, it's supported on all drives, even if
long names will be truncated on some drives.
> 4) I think there is a need for _USE_LFN to be publicly available.
I agree - and it is - by looking at the state of the flag in crt0_flags.
Look at djtar, for example.
> 5) Currently, `_use_lfn' is used by some library functions in the
> midst of moving data to the transfer buffer.
The way this needs to be done is:
1) Put the LFN detection code in a routine called from crt0, and have
it be the code currently in _use_lfn() (under a different name).
2) make use_lfn() do nothing but return the state of the crt0 flag.
This was the plan all along, it just never got implemented.
> 6) What about other flags that 71A0 returns? One flag that's
> particularly interesting is the case-preserving bit. Should we revise
> the functions that down-case filenames if this flag is ON? (Btw, Emacs
> currently assumes that if LFN is ON, filenames should not be
> automatically downcased.)
This becomes a libc re-write to store the characteristics of each drive
separately - and then provide info to the user on USE_LFN on a volume
by volume basis - and then mess with case selectively.
Since all of this code goes in every image, I didn't want to make it
bad for the straight DOS users. My feeling was if LFN was on you assumed
it was everywhere. If you don't like that, then disable it, or don't
use your crippled drives.
What I would suggest needs to be done about LFN is probably no more than
15 minutes coding - and will only change two files - and I haven't seen
a huge need for more changes than this yet. The init code for LFN needs
to go between setup_environment and __crt0_setup_arguments. I don't see
any way to support enabling this from DJGPP.ENV since we have already
expanded the globbed command line by the time we load DJGPP.ENV. Unless
someone wants to re-write the crt0_setup_arguments stuff. I would say
remove the LFN from the DJGPP.ENV file, and document it must be a real
ENV variable.
- Raw text -