Date: Mon, 29 Jul 1996 13:53:03 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: djgpp-workers AT delorie DOT com
Subject: USE_LFN woes
Message-Id: <Pine.SUN.3.91.960729131323.26664B-100000@is>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I'm rewriting the `_use_lfn' function and everything that's connected with
that.  Since I don't feel I know enough about the LFN API and don't have
an easy way of testing things, I decided to post my comments on the 
problems here and ask people for thoughts and advice.  (Sorry for this 
long message.)

	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 
immediately.  Calling `getenv' every time we need to know whether LFN is 
supported is too expensive, so I defined a static variable that gets 
incremented every time `putenv' is called, so that by comparing its value 
with the last seen value should tell if something's changed in the 
environment; if not, we can safely not call `getenv'.  Any comments on 
this design?

	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.

	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?

	4) I think there is a need for _USE_LFN to be publicly available. 
If a program needs to work on both LFN and non-LFN platforms, sometimes
there is no other way but to change the behavior at runtime.  Emacs is one
example: it converts some filenames built into Emacs (like ".emacs") into
names that are legal on native MSDOS, but leaves them unaltered when LFN
is supported.  Another example is Makeinfo from the latest port of Texinfo
3.7: it creates .iNN files on MSDOS and .info-NN under LFN. If it is
accepted that applications should be able to test _USE_LFN, then its
definition and declarations should move from <libc/dosio.h> to a public
header; I suggest <fcntl.h> (because it is already included by most 
programs that do file I/O).  Comments?

	5) Currently, `_use_lfn' is used by some library functions in the 
midst of moving data to the transfer buffer.  To assuage the possible 
damage, `_use_lfn' itself uses the space at the end of the transfer 
buffer, but this is still dangerous, since there is no way to know how 
much of the buffer is currently in use.  Do we really need to be able to 
call `_use_lfn' when some of the transfer buffer is used?  If so, I think 
it should use its own DOS buffer.  If we don't need this feature of 
`_use_lfn', then I think it is a simple matter of rearranging the code so 
it is never called when the transfer buffer is used.

	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.)

Whew!  Such a small function with such a complicated consequences...
Thanks in advance for any thoughts.