http://bugs.winehq.org/show_bug.cgi?id=26423
--- Comment #3 from Spammer spammis@spam.la 2011-08-17 05:26:44 CDT --- I haven't tried applying any of the patches, but I looked a bit at the source code. As I see it, Wine will use its short name in Dosbox (e.g. PROG~FBU for Program Files) while Dosbox will support both Dosbox and Wine short names (PROGRA~1 and PROG~FBU). This should fix the problem on UNIX partitions (e.g. ext4) and, until bug 26625 has been solved, also on NTFS partitions. However, if I've got things right, it won't help on FAT partitions.
As a little example, I created two files on a FAT partition: echo a > longfilename2 echo '' > longfilename1 You can tell the files apart by looking at the file size: longfilename1 is 1 byte while longfilename2 is 2 bytes (since each echo call ends with a UNIX line break). Since the partition type is FAT, real short names were created by the system based on the order of creation and stored on disk. The file longfilename2 was created first, so it gets ~1 while longfilename1 gets ~2.
"wine cmd /c dir /x" returns:
8/17/2011 11:56 AM 1 LONGFI~2 longfilename1 8/17/2011 11:56 AM 2 LONGFI~1 longfilename2
So Wine preserves the real short names. Dosbox, on the other hand, ignores the real short names and invents its own names. A "dir" call in Dosbox returns the following:
LONGFI~1 2 17-08-2011 11:56 LONGFI~2 1 17-08-2011 11:56
As you can see by comparing file sizes, Wine and Dosbox swap the names of these files.
I assume that this is a bug in the Wine/Dosbox integration, although maybe not a very important one. The integration only fails on FAT partitions, and it doesn't even always happen on those partitions. Sometimes, if you are lucky, real and Dosbox short names may happen to be the same on a FAT partition.