Short strings and short filnames in descriptions

[dandv 0]

1. When you enter a description to a file, NDN stores in descript.ion/00_index.txt/etc. the short file name. This is WRONG because SFNs are unpredictable and will most likely change when files are copied outside NDN from one place to another. Plus, on burned CDs, SFNs follow some strange rules (the last 2-3 chars of a

LFN *always* become ~4, ~6, ~8 etc. even if the first 5-6 chars are not the same).

 

descript.ion handling MUST be changed to LFNs.

 

2. File descriptions are still handled with old-string code which limits them to 255 characters. This has the nasty effect of truncating manually entered descriptions (typed in descript.ion, not enterd via Alt+Ins) when you copy a file with a length(LFN)+length(description) > 255. Worse, in the resulting descript.ion, the filename will be truncated to the SFN but the description won't benefit from the extra characters:

 

"longfilename.ext" [255-char description here] =>

longfi~1.ext [237-char description here]

 

Hope this helps,

Dan Dascalescu

[AngelsHolocaust 0]

hi dan!!

 

1)

don't say it is WRONG, because it is not, its just not perfect!

you mentioned 2 good points with outside copying and CD burning (although i cannot verify the Cd burning)

 

but, an example for SFN:

how do you want to find a LFN if you are in DOS?

 

(and please, do not answer me with something like

"noone uses dos anymore" :P)

 

also, we should look if there is a standard regarding BBS/DESCRIPTION FILES , and we should follow that (no matter how old it is), additionally i suggest an option to toggle LFN/SFN description handling

 

2) although i doubt that many ppl need descriptions of length > 255 (hehe, just speaking about myself) i also think we should be able to handle longer strings

 

thanks

 

Stefan/AH

[dandv 0]

you mentioned 2 good points with outside copying and CD burning (although i cannot verify the Cd burning)

I've been verifying the variability of CD SFNs since 1999:

1) the SFNs vary depending on the CD burning program used (for example, some sort filename case INsensitively and assign the SNFs with a step of 2: 4, 6, 8 etc. while others sort case sensitively)

2) WORSE, the SFNs depend on OS! Here is an actual example of the same CD read with Win98SE and Win2K:

 

Win98:

• 4NONBL~6.MP3 4 Non Blondes - What's Up.mp3 [!: analog noise @ EOF]
• ACEOFB~8.MP3 Ace of Base - Lucky Love.mp3 [!!!: 112 kbps]
• ACEOF~10.MP3 Ace of Base - Never Gonna Say I'm Sorry.mp3
• AQUA-~12.MP3 Aqua - Barbie Girl.mp3 (NICE; perfect earphone quality but pseudo-click 0:04, 0:07, 3:07 on source CD and +1 copy)

Win2K:

• 4nonbl~2.mp3 4 Non Blondes - What's Up.mp3 [!: analog noise @ EOF]
• aceofb~5.mp3 Ace of Base - Lucky Love.mp3 [!!!: 112 kbps]
• aceofb~8.mp3 Ace of Base - Never Gonna Say I'm Sorry.mp3
• aqua-b~b.mp3 Aqua - Barbie Girl.mp3 (NICE; perfect earphone quality but pseudo-click 0:04, 0:07, 3:07 on source CD and +1 copy)

how do you want to find a LFN if you are in DOS?

 

In this bug report, as well as in every post from now on, I'll be talking only about the Win32 version.

 

A more general solution, which I do NOT recommend, would be to:

1) when writing descriptions, write the same description for both the LFN and the SFN, just in case someone uses the DOS version of NDN, under DOS, on the same drive.

I used this solution myself until 1 year ago when burning CDs: I made a Perl script which computed the SFN on the CD and added to descript.ion the same description from the LFN entry but with the SFN. It worked, but only some times (depending on which burning program was used; I got it working for Nero, but WinOnCD stored SFNs in a different way!). I stopped adding SFN descriptions when I realized that Win2K assigned the SFNs in a totally different way.

 

2) when reading descriptions, if more than one description is found for a given file, pick the one from the longest filename.

 

also, we should look if there is a standard regarding BBS/DESCRIPTION FILES , and we should follow that

The standard for descriptions is pretty clear:

<filename|"filename"> (space|Tab)+ <description> <EOLN>

 

This standard is followed by NDOS (descript.ion), WhereIsIt (the leading CD cataloguing tool), DNOSP, FAR etc.

 

although i doubt that many ppl need descriptions of length > 255 (hehe, just speaking about myself) i also think we should be able to handle longer strings

 

Agree, here's a sample description I use:

 

"The Time Machine.avi" 66/100; 1:30:32/1:32:57; 640x272 DivX3 LowMotion @ 23.976 fps & var. keyframe freq., 899.8 kbit/s, Qf: 0.216 bits/pixel; 48kHz Joint Stereo incorrectly formatted (VDub complains), synchronized and normalized 141kbps VBR MP3; perfect underlying file & loudspeakers/video quality