RE: This LFN stuff is getting confusing...

Hi all, time for a posting to the list again, as Bart is still
improving my LFN understanding :-).

So what I got until now:
The kernel does not use LFN at all, but it does use short file names on
FAT 12/16/32 (28) drives, and it does use a networking API to allow client
drivers to provide it with networked drives (int 2f thing).

LFN aware applications use an API in int 21.71 (Windows text mode software
and djgpp 32bit DOS software can be in this group). Special drivers for
DOS provide this API without messing with the short file name functions
(apart from telling DOS to update its buffers and things like this). This
means the LFN for DOS driver needs to find the right sectors to access the
directory at sector level, but putting the LFN API right into the kernel
would increase the kernel size a lot, but lfnapi.c is there already, if
somebody dares to compile the kernel with it... However, this is incomplete
as of now.

However, such an API does not server networked drives. So if you want LFN
on the net, your client driver needs to provide the LFN API itself.
Alternatively, it can provide a "redirector API" which would require the
kernel to do additional translation (or the LFN for DOS driver) to give LFN
- as far as I understood it.

I as a non-networker (at least DOS is non-networked for me, Linux
certainly is),
I personally would prefer the kernel LFN (but optionally, so one
can have a non-LFN and/or non-FAT32 kernel as well, to save RAM)
solution, plus having some networking client with builtin LFN API.
As opposed to driver LFN with a networking client without LFN.
Hm. Or a driver LFN that can use redirector LFN with a networking
client with at least LFN-able redirector services.

The big question, however, is the set of LFN aware software out
there. You would like to have LFN aware shell or at least LFN
aware versions of all shell builtin commands like copy and dir
that make use of LFN. This would give a good start: When the
shell displays that I am about to dosamp longfilename.mp3 and
LFN unaware dosamp thinks it opens longfi~2.mp3, I am still
quite happy.

Here some snippets from Barts mail for further clarification:
> "LFN aware software" = DOS applications that call the INT21/AX=71xx API.

> The FreeDOS kernel could provide the whole LFN API all by itself too (but
> that would make the kernel considerably larger), but in that case it still
> needs to call the network client using a networking interface redirector
> API for remote drives. That "LFN redirector API" does not exist now, so
> all existing network clients that want to provide long file names in
> anyDOS need to provide the int21 LFN API (and do more work than if they
> would only provide an int2f "LFN redirector API").

[about LFN in the kernel:]
> That's what Victor is doing: low level stuff (writing out the directory
> entries in directory FOO) is in lfnapi.c, which has been in the kernel
> source for sometime but is not compiled. High level: converting long
> filenames into short ones, preparing directory entries is in a TSR. I
> don't think he's made much progress recently though.
> 
> With that TSR, FreeDOS would provide an LFN API but only for the local
> drives. This would provide the same as the DOSLFN and LFNDOS TSRs do
> today, but hopefully in a more reliable fashion.

[last but not least, Bart writes that kernel 2027 is almost ready.
 he has sent something to Tom (for cross-checking, I guess) but Tom
 seems to be away (from mail)...]

Eric