Not sure what your situation really is here.
IIRC, the moment you copy or move any lfn files with software unable to handle lfn, they freeze to 8.3 format, including the "bloody~1.fuk" renamings.
Which sadly, killed the original Norton Commander for me back then.
Any software able to handle the lfn should also display them correctly.

Back in '95, Microsoft was the laughing stock of the OS community for making a fuzz about lfn support. If not to upgrade to a later OS, deal with it 😉

stanwebber wrote on 2022-05-06, 01:34:

first, i'm wondering if i even comprehend what the definition of lfn 'support' means in dos. is it just preserving long file nam […]
Show full quote

first, i'm wondering if i even comprehend what the definition of lfn 'support' means in dos. is it just preserving long file names or is it full-blown interaction with files no different than in windows? here is what i had in mind when i started looking into this:

i want to use a win95 rtm laptop to manage files on a fat32 logical drive in the 2nd partition on a cf card via a pcmcia adapter. i would be happy to just extract archives and copy files to and from the partition. i don't want to upgrade the os or dual boot.

i figured i could create a win98se boot floppy and install a dos file manager with purported lfn support. i selected dos navigator open source project and obtained the extended mode 32bit lfn binaries, but i'm still only seeing 8.3 filenames. in fact, in the settings it even allows you to disable lfn for selected drives so i know i have the right release.

what am i missing here? is my expectation of having full-blown interaction with long filenames ala windows in dos just wrong-headed? at this point i'm starting to look around for a floppy-sized linux distribution with a basic graphical (or even text based) file manager.

Have you tried running that DOS navigator in a DOS prompt running under Windows ? Does it work as expected then ?

EDIT: also, can you be more specific as to which "dos navigator open source project" you are referring to. There seems to be more than one thing going by that name or something similar .

it's always something stupid simple that trips me up. i guess my ego always drives a complex solution.

despite being the basis for win9x, i discovered the dos7.0/1 kernel has no lfn awareness period. just copying a file will trash the lfn. you need to load a tsr in dos much like you would load a kernel module in linux. i used doslfn.com from the msdos 7.1 cdu release, although i understand freedos also provides a tsr.

the dn osp i obtained from https://www.bttr-software.de/freesoft/fileman1.htm picks up the long file names without issue.

There's a misunderstanding, maybe.

MS-DOS 7.1/8 doesn't provide LFN on its own, but it is LFN "aware".
Like the more recent DOS applications it runs.
The included commands DIR, COPY, XCOPY etc are LFN aware.

On Windows 9x, MS-DOS is under control of the Virtual Machine Manager and gets LFN support.
If it's running on its own, it needs a TSR, yes.

But then programs mentioned here do support LFN:
http://individual.utoronto.ca/wengier/doslfns.htm

Please note that the list isn't complete.
Most DOS ports of newer projects do include LFN support, I suppose.
Like those of the emulation scene up until 2005 or so.
ZSNES, for example, comes to mind.
("Quick load menu now shows full internal names or if LFN, as much as the other ports show.")
https://www.zsnes.com/index.php?page=news

That being said, LFN support is an odd thing. It's technically "there", but seldomly used on purpose.
It's rather some odd feature DOS veterans try to not think about.
DOSBox has that feature, too, but it's disabled by default.
Just like V86/EMM386 mode, it must be enabled during compile time, if memory serves.

LFN simply causes unnecessary headaches in the hands of novices, I'm afraid.
It's already hard enough to make them stick to 8.3 convention, I think.
No idea what happens if they assume long file names to be supported in DOS in general.
How to explain that just a minority of programs do support them?

Jo22 wrote on 2022-05-06, 15:05:

MS-DOS 7.1/8 doesn't provide LFN on its own, but it is LFN "aware".

Don't forget MS-DOS 7.0, the one that is with Windows 95 prior OSR2. 😉

DOSBox has that feature, too, but it's disabled by default.

Only DOSBox-X and DOSBox SVN-lfn has that feature, where in the former the DOS version must be set to 7.1.

LFN simply causes unnecessary headaches in the hands of novices, I'm afraid. It's already hard enough to make them stick to 8.3 […]
Show full quote

LFN simply causes unnecessary headaches in the hands of novices, I'm afraid.
It's already hard enough to make them stick to 8.3 convention, I think.
No idea what happens if they assume long file names to be supported in DOS in general.
How to explain that just a minority of programs do support them?

True.

The most dangerous utilities are the ones with direct disk access support which can damage the disk data if they aren't LFN capable and there isn't much awareness into this. Even loading a LFN driver into high memory is quite risky a real mode UMB driver.

Gmlb256 wrote on 2022-05-06, 15:22:

Even loading a LFN driver into high memory is quite risky a real mode UMB driver.

?

maxtherabbit wrote on 2022-05-06, 15:48:

Gmlb256 wrote on 2022-05-06, 15:22:

Even loading a LFN driver into high memory is quite risky a real mode UMB driver.

?

Due to the way how UMB is generated by using memory meant for shadow RAM, it may or may not be capable of doing ISA DMA transfers in those regions and DOSLFN (and disk caching utilities) relies on that for floppy disk support.

LOWDMA.SYS can be used as a workaround but it isn't that perfect.

Gmlb256 wrote on 2022-05-06, 15:56:

maxtherabbit wrote on 2022-05-06, 15:48:

Gmlb256 wrote on 2022-05-06, 15:22:

Even loading a LFN driver into high memory is quite risky a real mode UMB driver.

?

Due to the way how UMB is generated by using memory meant for shadow RAM, it may or may not be capable of doing ISA DMA transfers in those regions and DOSLFN (and disk caching utilities) relies on that for floppy disk support.

LOWDMA.SYS can be used as a workaround but it isn't that perfect.

Ok sure but that's a UMB/motherboard specific problem. Has nothing to do with LFN specifically, any TSR or driver you load to UMB will have that issue if it requires DMA and your motherboard has that limitation. If you want real mode UMBs it's your responsibility to sort that out. In my case, I just ensure DOSLFN et al. are loaded to the 'E' segment of UMB which does support DMA on all my intel 430/440 chipsets

maxtherabbit wrote on 2022-05-06, 16:59:

Ok sure but that's a UMB/motherboard specific problem. Has nothing to do with LFN specifically, any TSR or driver you load to UMB will have that issue if it requires DMA and your motherboard has that limitation. If you want real mode UMBs it's your responsibility to sort that out.

Agreed. This really depends of the motherboard chipset and not something for a beginner when dealing with TSRs.

In my case, I just ensure DOSLFN et al. are loaded to the 'E' segment of UMB which does support DMA on all my intel 430/440 chipsets

Same here with my both Socket 7 and Slot 1 computers. Still many aren't aware of this because they don't RTFM.

i can load doslfn high on this laptop since dmachk reports that all upper memory areas can support isa dma.

conversely, my athlon system has 0 upper memory addresses supporting isa dma and it's mandatory to use dos=noauto when enabling umbs.