VOGONS

Common searches


Long File Name (LFN) support

Topic actions

Reply 40 of 104, by wackee

User metadata
Rank Newbie
Rank
Newbie

Thank you for investigating the issue.

I checked one of your observations though:
"This enumeration issue in StarCommander does not appear to be linked to a large number of files."

To check it, in 8.3 mode I created a dir and copied ~400 short filenamed files there. Unfortunately, only 31 files are enumerated. This is with LFN flag turned off in DosBox.

Here is a screenshot:
sc1.png

Reply 42 of 104, by Wengier

User metadata
Rank Member
Rank
Member

Hi,

Thanks for testing the LFN patch and report the issue with StarCommander when there are many files present in the directory. I had a quick look at it. While I have not yet found the exact cause of the problem, the issue itself seemed to vanish (at least on my computer) when I added a trivial statement like printf in the source code. Sorry I really don't have much time to investigate in great details at the moment. I have uploaded the version of DOSBox LFN with this workaround applied as an attachment. Please check if it works on your computer. Also note that this version has the patches from the latest DOSBox SVN version (r3876) applied as well.

Attachments

  • Filename
    dosboxlfn.zip
    File size
    1.76 MiB
    Downloads
    86 downloads
    File license
    Fair use/fair dealing exception

Reply 43 of 104, by truth_deleted

User metadata

Thank you, Wengier, for so quickly and easily correcting the issue! I confirmed that doszip commander and star commander now display the files correctly, although I plan to further test so I don't miss scenarios that wackee helpfully identified.

The only issue left is in star commander where the date and file size is reported as a single value for all files. Perhaps you could confirm? If not, I'll work on a screenshot so I don't leave you with this incomplete description. 😀

Another much more minor issue is in doszip: it's possible to view a long file name file, but not edit it (both view and edit are built-in doszip functions). However, where setting all LFNs to SFNs, then both functions work correctly. I think a similar thing happens in star commander.

Reply 44 of 104, by Wengier

User metadata
Rank Member
Rank
Member
truth5678 wrote:

Thank you, Wengier, for so quickly and easily correcting the issue! I confirmed that doszip commander and star commander now display the files correctly, although I plan to further test so I don't miss scenarios that wackee helpfully identified.

The only issue left is in star commander where the date and file size is reported as a single value for all files. Perhaps you could confirm? If not, I'll work on a screenshot so I don't leave you with this incomplete description. 😀

Another much more minor issue is in doszip: it's possible to view a long file name file, but not edit it (both view and edit are built-in doszip functions). However, where setting all LFNs to SFNs, then both functions work correctly. I think a similar thing happens in star commander.

I can confirm that Star Commander reports file size as a single value for all files, but not if LFN is set to false. The problem however is that I don't know exactly which data field Star Commander wants in order to display the file size correctly when LFN is enabled, since other file managers like DosZip Commander do show file size correctly even in LFN mode. Maybe there is something else that Star Commander expects for displaying file size in LFN mode?

Since I don't have much time for detailed analysis currently, I will try to investigate this issue further later. Thanks both of you for letting me know the problem however.

Reply 45 of 104, by Wengier

User metadata
Rank Member
Rank
Member

As for the file editing issue in DosZip Commander, I have checked that the problem only occurs if there is a space in the long file name. I have fixed the issue, and the Windows binary can be downloaded from:

https://bitly.com/12jANWF

Reply 46 of 104, by wackee

User metadata
Rank Newbie
Rank
Newbie

Dear Wengier,
Thank you so much for the work you've done so far, this is a great improvement for us SC users, even if it's only a workaround.
And doing this so quickly, taking into account holidays etc, you have my utmost respects and gratitude.

Reply 47 of 104, by truth_deleted

User metadata

Thank you for the fixes! I originally failed to test a mingw build of dosbox with LFN support. The mingw build does work, and since the printf statement corrects the issue for you (VS build?), then it seems probable that the issue (first reported) was a compiler optimization bug.

On the other question on file size and date in star commander while its LFN option is turned on (no issue where it is turned off): I verified that the file sizes are not fully reported on screen, but actually the size is 2,147,483,647 (as shown via the file info menu item in star commander). If I may guess, I would think the issue would involve use of a 32-bit integer variable (since the file size is exactly the maximum value of a 32-bit integer) or even the size of the reported hard drive; however, it is not an issue in doszip commander as you noted. There is also a small chance that star commander is performing some low level access, but only where LFN is active.

Edit: confirmed that running a dos image in dosbox avoids the star commander issue of displaying the incorrect file size and date while LFN is active.

Found this blurb about star commander (unfortunately the beta source code is not released):
SC 0.90.02 beta (2012-01-27)
Changes since SC 0.90.01 beta:
Fix: Lots of bugs, caused by code restructuring and integer size problems.

It would be necessary to test SC 0.90.02 beta to verify that the file size issue was not inadvertently fixed in the latest beta release, although I'm not hopeful. However, the newest beta version is not available. Perhaps the poster who reported the bug could notify the star commander developer and request the newest beta version, especially since the issue doesn't occur in doszip commander. He may be able to provide clues, too.

Reply 48 of 104, by truth_deleted

User metadata

From the Star Commander source code, file sysint.asm, there is reference to the int21h LFN commands, particularly this: 57H - Get/Set file date and time. Verified that your LFN emulation has many of the functions listed in sysint.asm, but AH=57H is not. There's also a reference to 36H - Get disk free space.

Is it possible that Star Commander has two different routines to get the file date? It may look for AH=57H where LFN is active, but use another routine where LFN is not active?

Reply 49 of 104, by Wengier

User metadata
Rank Member
Rank
Member
truth5678 wrote:

From the Star Commander source code, file sysint.asm, there is reference to the int21h LFN commands, particularly this: 57H - Get/Set file date and time. Verified that your LFN emulation has many of the functions listed in sysint.asm, but AH=57H is not. There's also a reference to 36H - Get disk free space.

Is it possible that Star Commander has two different routines to get the file date? It may look for AH=57H where LFN is active, but use another routine where LFN is not active?

I believe AH=57H refers to Int21/AX=5700H, which is a standard Int21 API, not a LFN-specific API. There does not exist an LFN version of this function. Instead, Star Commander and DosZip Commander will use the info in the Win32 find data structure by calling AX=714E/714Fh when LFN is active, and this structure contains information such as file name, size and date. When LFN is inactive, they will use the size info stored in the DTA (Disk Transfer Area) after calling AX=4E00/4F00h. The problem however is that when in LFN mode Star Commander does not seem to use the file size info set in the corresponding Win32 find data field according to the specification I have. The data should already have been correctly set by DOSBox LFN, otherwise DosZip Commander would not show correct file size in LFN mode either.

Reply 50 of 104, by truth_deleted

User metadata

Very interesting! Thank you for lending your expertise in explaining in detail how software retrieves the file data. I had a naive understanding of how it works. 😀

Equipped with that information, I would like to examine the Star Commander source code again. I don't expect to make any insight, but I think the C64 community could consider asking the maintainer of that project to document the way it retrieves file data while LFN is active.

Reply 51 of 104, by truth_deleted

User metadata

Edit: I removed my question about star commander and calls to 4e00 and 714e, especially since Wengier already clearly explained it. 😀 To satisfy my own curiosity, I confirmed that star commander accesses 714e where long file name is active; did this via printf statements which show entry into the 714e function. It took me a while to understand the basics of this area of emulation.

Edit2: In addition, star commander is correctly sorting the files by file size while LFN is active! Even though the reported file size is the same value for all files (maximum 32bit value). I wonder whether star commander is correctly reading the win32 file data in LFN mode, but it doesn't display it correctly. Lending some support for this is that the "view file" function also shows the correct file size while LFN is active. Confirmed that the copy function works correctly, too.

Reply 52 of 104, by cyberwalker

User metadata
Rank Newbie
Rank
Newbie
dosbox_lfn_g_issue.png
Filename
dosbox_lfn_g_issue.png
File size
23.53 KiB
Views
1935 views
File license
Fair use/fair dealing exception

The patch seems good. Finally DJGPP works in DosBox and is much faster than in Qemu. So far I have just found the following issue with the patch: the console output is incorrect in graphic mode. I hope the patch gets fixed and then merged into the official build.

SQLite compiled for DOS/DPMI

Reply 53 of 104, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Is there a updated patch / diff file for the feature LFN support? The latest downloads all seem to be the whole source. I'm especially interest in Joliet cdrom lfn support, since the game i'm trying (Noir on cd 2) has that problem. If it works with mount directory as cdrom even better.

I'm interested in stealing it for my build. I'll probably modify the defaults so it's not on (because i only really want to use it with windows 3.1 games and don't want to risk other apps being broken).

Reply 54 of 104, by Wengier

User metadata
Rank Member
Rank
Member
Serious Callers Only wrote:

Is there a updated patch / diff file for the feature LFN support? The latest downloads all seem to be the whole source. I'm especially interest in Joliet cdrom lfn support, since the game i'm trying (Noir on cd 2) has that problem. If it works with mount directory as cdrom even better.

I'm interested in stealing it for my build. I'll probably modify the defaults so it's not on (because i only really want to use it with windows 3.1 games and don't want to risk other apps being broken).

The source download contains source files that are changed from the original version of DOSBox, not the whole source of DOSBox. Simply replace the original files with the changed source files, it should probably work. Sure, you can use them for your own build.

Reply 55 of 104, by Wengier

User metadata
Rank Member
Rank
Member
cyberwalker wrote:
dosbox_lfn_g_issue.png

The patch seems good. Finally DJGPP works in DosBox and is much faster than in Qemu. So far I have just found the following issue with the patch: the console output is incorrect in graphic mode. I hope the patch gets fixed and then merged into the official build.

I really hope they will be integrated into the official build too, but the main developers of DOSBox seem to be primarily focus on games, so..

Reply 56 of 104, by Serious Callers Only

User metadata
Rank Member
Rank
Member
Wengier wrote:
Serious Callers Only wrote:

The source download contains source files that are changed from the original version of DOSBox, not the whole source of DOSBox. Simply replace the original files with the changed source files, it should probably work. Sure, you can use them for your own build.

Sorry but that will simply not work with a constantly updating svn build, like the one i have. Without using diffs that would break 99% of the time and stay broken once i give up on it.
It's not all about me though 😉. I'm pretty sure that a non-diff will be harder to update on the long run, and will get so bitrotted eventually that people have to go back to the original versions you started with, make a proper diff and then try to port your changes to svn eventually.

Have you looked on collaborating with other people like these here that are trying to work with your patch?

https://github.com/joncampbell123/dosbox-x/issues/105

Reply 57 of 104, by Wengier

User metadata
Rank Member
Rank
Member
Serious Callers Only wrote:
Sorry but that will simply not work with a constantly updating svn build, like the one i have. Without using diffs that would br […]
Show full quote
Wengier wrote:
Serious Callers Only wrote:

The source download contains source files that are changed from the original version of DOSBox, not the whole source of DOSBox. Simply replace the original files with the changed source files, it should probably work. Sure, you can use them for your own build.

Sorry but that will simply not work with a constantly updating svn build, like the one i have. Without using diffs that would break 99% of the time and stay broken once i give up on it.
It's not all about me though 😉. I'm pretty sure that a non-diff will be harder to update on the long run, and will get so bitrotted eventually that people have to go back to the original versions you started with, make a proper diff and then try to port your changes to svn eventually.

Have you looked on collaborating with other people like these here that are trying to work with your patch?

https://github.com/joncampbell123/dosbox-x/issues/105

OK, a diff file against DOSBox SVN r3876 is now available from the attachment. It includes both LFN and mouse copy/paste patch, but for only the LFN patch, the changes in the files sdlmain.cpp, mouse.cpp, mouse.h and curses.h are not required.

I am interested in the link you give, but it seems to mainly talk about functions in non-Win32 or Linux port. I am afraid I can't really help with this particular part since I am not so familiar with Linux systems.

Attachments

  • Filename
    dosboxpatch.diff
    File size
    56.02 KiB
    Downloads
    88 downloads
    File license
    Fair use/fair dealing exception

Reply 58 of 104, by collector

User metadata
Rank l33t
Rank
l33t

You might want to a take a look at his DOSBox-X branch thread here. It includes Win32.

DOSBox-X branch

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 59 of 104, by Wengier

User metadata
Rank Member
Rank
Member
collector wrote:

You might want to a take a look at his DOSBox-X branch thread here. It includes Win32.

DOSBox-X branch

Thanks for the link, but are there any attempts to merge the LFN patch into his Win32 port in that thread yet?