libfat returns LFN for 8.3 files in dirnext()

Got something cool to help make the toolchains better? Post it here.
Post Reply
avenir
Posts: 8
Joined: Sat Feb 05, 2011 11:23 pm

libfat returns LFN for 8.3 files in dirnext()

Post by avenir » Sun Feb 06, 2011 12:03 am

dirnext() returns boot.nds instead of BOOT.NDS, so (also for 8.3 files) you will see the same file name as on WinXP PC.
Last edited by avenir on Fri Feb 11, 2011 2:32 pm, edited 2 times in total.

WinterMute
Site Admin
Posts: 1404
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: libfat returns LFN for 8.3 files in dirnext()

Post by WinterMute » Mon Feb 07, 2011 3:07 am

What problem does this patch solve?
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog

avenir
Posts: 8
Joined: Sat Feb 05, 2011 11:23 pm

Re: libfat returns LFN for 8.3 files in dirnext()

Post by avenir » Mon Feb 07, 2011 3:11 am

WinNT uses reserved flag for filenames with all small characters like "boot.nds".
When there is such file, you can see "boot.nds" on WinNT but "BOOT.NDS" on libfat.
This patch will return "boot.nds" instead of "BOOT.NDS" for such case.

And it seems that I can't see bootlib with decreased size, so I re-attach it

WinterMute
Site Admin
Posts: 1404
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: libfat returns LFN for 8.3 files in dirnext()

Post by WinterMute » Tue Feb 08, 2011 12:36 pm

I'm still not clear on the problem that's solved here.

What difference does it make? VFAT isn't case sensitive so this is nothing more than a cosmetic change as far as I can determine.

Your "bootlib" patch removes essential functions from hbmenu so it was removed. Please don't post it again.
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog

avenir
Posts: 8
Joined: Sat Feb 05, 2011 11:23 pm

Re: libfat returns LFN for 8.3 files in dirnext()

Post by avenir » Tue Feb 08, 2011 1:15 pm

WinterMute wrote:this is nothing more than a cosmetic change as far as I can determine.

Your "bootlib" patch removes essential functions from hbmenu so it was removed. Please don't post it again.
1. As for NT flag, yes it is cosmetic change, but it is what libelm(Wood/AKAIO) and MoonShell are doing.
[edit]but it is big problem if the software sorts filenames case-sensitive.
But 0xe5 problem is important; if you create a file whose first alias char is 0xe5, the file got marked as "deleted".

2. What do you mean? DSi SD wasn't usable? Here the thumb code bootlib works normally and bootstub was also OK.

WinterMute
Site Admin
Posts: 1404
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: libfat returns LFN for 8.3 files in dirnext()

Post by WinterMute » Tue Feb 08, 2011 4:21 pm

libelm isn't compatible with libfat and not supported by devkitPro.

What AKAIO, Wood and Moonshell do is mostly irrelevant unless it interferes with the proper functioning of devkitARM and its associated libraries.

Case sensitive filename sorting on a case insensitive file system seems a bit silly but still doesn't seem to be anything other than a minor cosmetic issue.

hbmenu is not a DSi only project nor will modified binaries for specific DS model consoles be provided. The bootloader provider with hbmenu is not a library, nor is it intended for use in normal user code.

Explain the 0xE5 thing in more detail. Under what circumstances does this become an issue? How does the user end up with a file that starts with this character and isn't deleted?
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog

avenir
Posts: 8
Joined: Sat Feb 05, 2011 11:23 pm

Re: libfat returns LFN for 8.3 files in dirnext()

Post by avenir » Wed Feb 09, 2011 12:42 am

WinterMute wrote: hbmenu is not a DSi only project nor will modified binaries for specific DS model consoles be provided. The bootloader provider with hbmenu is not a library, nor is it intended for use in normal user code.

Explain the 0xE5 thing in more detail. Under what circumstances does this become an issue? How does the user end up with a file that starts with this character and isn't deleted?
1. Actually I have modified bootlib to blink power LED during loading code. The modified bootlib exceeded 40KB and overflew bootstub area. So I needed to reduce the size by using thumb code.
Anyway I'm unsure why you removed my bootlib.patch. It is 90% just Makefile change.

2. Some Chinese character's first byte is 0xE5.

PS. This bootlib.patch contains another patch.
Actually dldi_startup_patch isn't required at all. It will break "homebrew loaded from another homebrew loaded from hbmenu".
"a homebrew game loaded by MoonShell loaded by hbmenu" crashed on AK2i due to lack of actual dldi_startup.
[edit] If you think users won't do that, read sentence again with replacing hbmenu with DSision.

WinterMute
Site Admin
Posts: 1404
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: libfat returns LFN for 8.3 files in dirnext()

Post by WinterMute » Wed Feb 09, 2011 12:25 pm

1. Actually I have modified bootlib to blink power LED during loading code. The modified bootlib exceeded 40KB and overflew bootstub area. So I needed to reduce the size by using thumb code.
Why? blinking LED is either a cosmetic change or something you use for debugging.

I tried compiling code as thumb a while ago and it failed. The TODO list does have a note on this & the intent to figure out why.
2. Some Chinese character's first byte is 0xE5.
Any chance you could get me a fat image containing files like this for testing?
Actually dldi_startup_patch isn't required at all. It will break "homebrew loaded from another homebrew loaded from hbmenu".
"a homebrew game loaded by MoonShell loaded by hbmenu" crashed on AK2i due to lack of actual dldi_startup.
[edit] If you think users won't do that, read sentence again with replacing hbmenu with DSision.
That may depend on the card or it may be a bug in Moonshell. Some cards fail when the init code is rerun but the card should be already initialised when homebrew is launched. This sounds like Moonshell may well be shutting down the card before launching homebrew which may not be a good idea. While testing the dldi process we found many anomalies in the way cards handle the initialisation of SD cards like the startup code causing an already initialised card to fail and having no dldi section (for cards with default DLDIs that fail on arm7) causing the SD to not start up at all.

This is unfortunately still a really difficult thing to support in a clean and consistent manner, especially when people insist on submitting patches that are only tested on one or two flashcards. Hbmenu has been tested on somewhere in the region of 50 or 60 cards now.
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog

avenir
Posts: 8
Joined: Sat Feb 05, 2011 11:23 pm

Re: libfat returns LFN for 8.3 files in dirnext()

Post by avenir » Wed Feb 09, 2011 12:59 pm

WinterMute wrote: I tried compiling code as thumb a while ago and it failed. The TODO list does have a note on this & the intent to figure out why.

Any chance you could get me a fat image containing files like this for testing?
1. possibly because you didn't compile arm9 part in ARM.
2. later

WinterMute
Site Admin
Posts: 1404
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: libfat returns LFN for 8.3 files in dirnext()

Post by WinterMute » Fri Feb 11, 2011 1:48 pm

Embarrassingly I somehow read your original patch as removing the DLDI patching which probably confused you about "essential functionality" and "DSi specific" so, oops, sorry. The patching out of startup code is still a bit peculiar, I think I might need to dig out some cards where it failed and see if it can be compensated somehow. Of course we could always just decide not to support those cards where it fails, I do have a vague memory of those being slot2 cards.

I've committed changes to build as thumb now, next thing I want to look at is collating the reads to maximise the number of sectors read at a time instead of the sector at a time approach that's in there now. That's dog slow from the DSi SD due to some odd delays on each read operation.
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests