10-19-2016, 03:01 AM
Post: #422
 Claudio L. Senior Member Posts: 1,734 Joined: Dec 2013
(10-18-2016 11:12 PM)matthiaspaul Wrote:  Knowing that the 49g+/50g firmware can or could create such invalid SFNs, perhaps newRPL should be enhanced by adding a little special case which would upcase 61h..7Ah in on-disk SFNs before filename comparisons in order to improve compatibility at least for direct file exchange. This would consume only a couple of bytes and not be conflictive with normal file access as these characters cannot normally occur in SFNs.

I should clarify that when you select the case-sensitive mode (default) there's no need. If there's a SFN with lowercase, the comparison will only match with lowercase letters in the search pattern, so it actually works as expected.
When case insensitive is selected, newRPL converts both:
Code:
 // CASE-INSENSITIVE while( __ICASE(*name1)==__ICASE(*name2) )
This is no coincidence. That bug (and others like bad fseek() and absence of frename()) is what prompted me to write my own file system driver in the first place, so the solution was put in place for compatibility back in the hpgcc days.
Now this is legacy code, which means I didn't upgrade it to Unicode. It will only change 'a' to 'z', but doesn't do proper Unicode case-folding. The utf library can do it, but I thought it was overkill, especially since the file system will be used 99.9% of the time in case sensitive mode.

(10-18-2016 11:12 PM)matthiaspaul Wrote:  I would like to suggest to extend this idea to the four special cases utilizing the two "case"-bits in the SFN discussed previously:
This can be done, but it's hard to find a use case where it actually helps.
I'd think that none of those bad implementations are case-sensitive, therefore any SFN written by those OS will be uppercase and there's nothing newRPL can do about it. On the other hand, a file written by newRPL would display the incorrect case if the OS doesn't support it, but the OS would be able to open the file normally, as the comparison would be case-insensitive (as you said, merely a cosmetic problem).
If such OS changes the directory entry it should preserve those bits, even if they don't support their behavior (otherwise it's a VERY bad implementation). If the file gets renamed, and the OS writes a completely new name, then the name will lose its case, but there's no way to solve this from newRPL. Even if newRPL writes a LFN, the OS might decide (during rename) that because the new name fits in 8.3 it doesn't get an LFN when it creates the new entry, and loses its case anyway.

Regarding the SFN fallback: I think if there's no room to create the entry, then file creation needs to fail and return an error (as-implemented). Creating a file with a name different from the requested one won't help the user find his file... not to mention that if there's no room for the directory entry the disk might be full. It's better to let the user know with an error, don't you think?
 « Next Oldest | Next Newest »