http://bugs.winehq.org/show_bug.cgi?id=26423
Summary: Wine should use MS-DOS (8.3) file names when interacting with Dosbox Product: Wine Version: 1.3.15 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dos AssignedTo: wine-bugs@winehq.org ReportedBy: spammis@spam.la
This depends on bug 26422.
Let's assume that the current directory is "C:\Program Files" (~/.wine/drive_c/Program Files). I type "wine dosprog" where "dosprog" is some MS-DOS program. Wine starts Dosbox and runs the following commands:
mount c /home/username/.wine/dosdevices/c: mount d /home/username/.wine/dosdevices/d: C: cd \Program Files C:\Program Files\dosprog.exe exit
Dosbox does not recognise long file names (Program Files); Dosbox requires short names (PROGRA~1). The "cd" call and the program call will both fail because of this.
http://bugs.winehq.org/show_bug.cgi?id=26423
Spammer spammis@spam.la changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |26422
http://bugs.winehq.org/show_bug.cgi?id=26423
Bug 26423 depends on bug 26422, which changed state.
Bug 26422 Summary: Wine and Dosbox use different MS-DOS (8.3) file names http://bugs.winehq.org/show_bug.cgi?id=26422
What |Old Value |New Value ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE
http://bugs.winehq.org/show_bug.cgi?id=26423
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
http://bugs.winehq.org/show_bug.cgi?id=26423
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Depends on|26422 |18292 Ever Confirmed|0 |1
--- Comment #1 from André H. nerv@dawncrow.de 2011-04-10 13:07:19 CDT --- I have hacked dosbox and winevdm here to get it working with the wine way of short file names, but it's still just hackish. Maybe i can convice dosbox to at least accept long paths
http://bugs.winehq.org/show_bug.cgi?id=26423
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source
http://bugs.winehq.org/show_bug.cgi?id=26423
--- Comment #2 from André H. nerv@dawncrow.de 2011-08-03 14:49:30 CDT --- DOSBox patch: https://sourceforge.net/tracker/?func=detail&aid=3382938&group_id=52...
Wine patch: http://www.winehq.org/pipermail/wine-patches/2011-July/105013.html
The wine patch waits for the dosbox patch to be applied.
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.
http://bugs.winehq.org/show_bug.cgi?id=26423
--- Comment #4 from André H. nerv@dawncrow.de 2011-08-17 11:09:00 CDT --- First, thx for taking the time to analyse this.
(In reply to comment #3)
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.
no, both time the 1-Byte has ~2 and the 2-Byte has ~1 It's a bit confusing, maybe it get's more clear with filesizes > 2 ;)
http://bugs.winehq.org/show_bug.cgi?id=26423
--- Comment #5 from Spammer spammis@spam.la 2011-08-18 06:42:35 CDT --- (In reply to comment #4)
no, both time the 1-Byte has ~2 and the 2-Byte has ~1 It's a bit confusing, maybe it get's more clear with filesizes > 2 ;)
Sorry, it was my fault, misreading things. I was mislead by the fact that the Windows version of Dosbox, running under Wine, uses the Wine short names in a very strange way for files stored on ext4 partitions. However, it seems that both the Windows version of Dosbox, running under Wine, and the Linux version of Dosbox, running natively under Linux, use the real short names for files and directories stored on FAT partitions. In any case, no problem with the Wine/Dosbox integration, as far as I can see.
http://bugs.winehq.org/show_bug.cgi?id=26423
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #6 from André H. nerv@dawncrow.de 2011-08-31 13:24:42 CDT --- fixed since dosbox svn 3743
and now also in wine: http://source.winehq.org/git/wine.git/commit/f9c6b4ba406d302a631c27994ee7ad8...
http://bugs.winehq.org/show_bug.cgi?id=26423
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org 2011-09-09 12:54:59 CDT --- Closing bugs fixed in 1.3.28.
http://bugs.winehq.org/show_bug.cgi?id=26423
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |f9c6b4ba406d302a631c27994ee | |7ad81986deb6c CC| |focht@gmx.net
--- Comment #8 from Anastasius Focht focht@gmx.net 2011-10-14 04:28:04 CDT --- Hello,
filling/correcting fields...
Regards
-
wine-bugs＠winehq.org