VOGONS


8.3 names bug.

Topic actions

First post, by Fj_

User metadata
Rank Newbie
Rank
Newbie

Have two folders with long names of "Lost Vikings 2" and "Lost Vikings", that have corresponding short aliases of "LOSTVI~1" and "LOSTVI~2" in that very order due to the order of creation. However, dosbox ignores short alias stored in the filesystem and names these folders in the alphabetical i.e. reverse order. That causes some confusion when using D-FEND frontend that uses correct short names from the OS.

However the bug is easily bypassed by renaming folders in a specific order.

DOSBOX 0.63
Windows 2003 server (enterprise) SP1

Reply 2 of 8, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

As has been said before: do not rely on names longer than 8.3. Not even windows itself uses consistent naming for them.

Reply 3 of 8, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

well it can be argued that if our names differ from the windows names that it's considered a bug

We never claim to use the ones windows uses.

Water flows down the stream
How to ask questions the smart way!

Reply 4 of 8, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

GetShortPathName in Kernel32.dll could do the trick, but then there is portability again...

Reply 5 of 8, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

portability goes above the match between windows names and dosbox names.

Water flows down the stream
How to ask questions the smart way!

Reply 6 of 8, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

How about just putting a warning and/or disclaimer about long filenames in the DOSBox readme?

Reply 7 of 8, by barfoot

User metadata
Rank Newbie
Rank
Newbie
HunterZ wrote:

How about just putting a warning and/or disclaimer about long filenames in the DOSBox readme?

Wait.. people read the readme file? I know I haven't been around these forums very long, but I got the feeling the biggest issue around here is that no one ever reads the readme.

Reply 8 of 8, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Agreed, but at least we'd be able to claim that we warned them and then lock the thread...