Long File Name (LFN) support (SDL1)

Here you can discuss the development of patches.

Re: Long File Name support

Postby wackee » 2014-12-23 @ 09:24

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:
Image
wackee
Newbie
 
Posts: 4
Joined: 2014-12-22 @ 19:44

Re: Long File Name support

Postby truth_deleted » 2014-12-23 @ 10:16

I think this will provide some documentation for Wengier on the issue. I tested with other lfn file managers with negative results. I checked the code and turning off lfn may still access the Int21h emulation, but I would have to confirm with further testing.
truth_deleted
 

Re: Long File Name support

Postby Wengier » 2014-12-24 @ 04:13

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.
You do not have the required permissions to view the files attached to this post.
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby truth_deleted » 2014-12-24 @ 04:50

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

Re: Long File Name support

Postby Wengier » 2014-12-24 @ 16:05

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.
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby Wengier » 2014-12-24 @ 17:07

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
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby wackee » 2014-12-24 @ 22:31

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.
wackee
Newbie
 
Posts: 4
Joined: 2014-12-22 @ 19:44

Re: Long File Name support

Postby truth_deleted » 2014-12-24 @ 23:22

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

Re: Long File Name support

Postby truth_deleted » 2014-12-25 @ 00:16

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?
truth_deleted
 

Re: Long File Name support

Postby Wengier » 2014-12-25 @ 02:33

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.
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby truth_deleted » 2014-12-25 @ 04:24

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

Re: Long File Name support

Postby truth_deleted » 2014-12-25 @ 05:39

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

Re: Long File Name support

Postby cyberwalker » 2015-6-22 @ 08:48

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.
You do not have the required permissions to view the files attached to this post.
SQLite compiled for DOS/DPMI
cyberwalker
Newbie
 
Posts: 58
Joined: 2004-11-24 @ 06:10

Re: Long File Name support

Postby Serious Callers Only » 2015-8-20 @ 21:20

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).
Serious Callers Only
Member
 
Posts: 370
Joined: 2003-4-26 @ 21:34

Re: Long File Name support

Postby Wengier » 2015-8-22 @ 16:27

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.
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby Wengier » 2015-8-22 @ 16:31

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..
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby Serious Callers Only » 2015-8-24 @ 19:28

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
Serious Callers Only
Member
 
Posts: 370
Joined: 2003-4-26 @ 21:34

Re: Long File Name support

Postby Wengier » 2015-8-26 @ 19:49

Serious Callers Only wrote:
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.
You do not have the required permissions to view the files attached to this post.
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby collector » 2015-8-27 @ 01:51

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

viewtopic.php?f=41&t=31881
User avatar
collector
l33t
 
Posts: 4156
Joined: 2003-1-15 @ 10:39

Re: Long File Name support

Postby Wengier » 2015-8-27 @ 02:00

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

viewtopic.php?f=41&t=31881


Thanks for the link, but are there any attempts to merge the LFN patch into his Win32 port in that thread yet?
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 4 guests