[Bug 23865] New: Microsoft Wine Guide (16-bit) unable to find files whose names end with .

http://bugs.winehq.org/show_bug.cgi?id=23865

Summary: Microsoft Wine Guide (16-bit) unable to find files
                    whose names end with .
           Product: Wine
           Version: 1.2
          Platform: x86
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: minor
          Priority: P2
         Component: -unknown
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

Created an attachment (id=29962)
 --> (http://bugs.winehq.org/attachment.cgi?id=29962)
+relay,+int21,+mmio log compressed with bzip2

This bug applies to Microsoft Wine Guide 1.0a, a multimedia CD-ROM from 1995
which works with Windows 3.1 and later.

The program is unable to read some files from the CD-ROM which have names
ending in a dot. For example:
$ ls -l /media/cdrom/mswptime/vo/
total 5142
-rwxrwxrwx 1 root root  136888 1995-01-28 12:48 bordeaux.
-rwxrwxrwx 1 root root  133676 1995-01-28 12:48 burgundy.
-rwxrwxrwx 1 root root   82410 1995-01-28 12:48 flute.
-rwxrwxrwx 1 root root  123796 1995-01-28 12:49 port.
-rwxrwxrwx 1 root root  206696 1995-01-28 12:50 red.
-rwxrwxrwx 1 root root 3494956 1995-04-05 13:00 score.
-rwxrwxrwx 1 root root   91972 1995-01-28 12:53 sherry.
-rwxrwxrwx 1 root root  705278 1995-01-20 15:07 title.
-rwxrwxrwx 1 root root  178492 1995-01-28 12:41 title.2
-rwxrwxrwx 1 root root  108658 1995-01-28 12:54 white.

The program appears to be trying to open the corresponding name without a dot.

Start wine.exe in the root directory of the CD-ROM. A Microsoft Home splash
window opens, and there are several error dialog boxes about DLLs; click Ignore
to dismiss each one. The main window then opens. A sound should play but
doesn't. This console output:
err:mmio:MMIO_ParseExtA No . in szFileName: "F:\MSWPTIME\vo\title"

Click WINE TASTING WITH OZ, then THE BASICS, then GLASSES. Each loudspeaker
icon should play a sound clip when clicked. Instead you get console output like
this (one line on clicking each button):
err:mmio:MMIO_ParseExtA No . in szFileName: "F:\MSWPTIME\vo\port"
err:mmio:MMIO_ParseExtA No . in szFileName: "F:\MSWPTIME\vo\sherry"
err:mmio:MMIO_ParseExtA No . in szFileName: "F:\MSWPTIME\vo\red"
err:mmio:MMIO_ParseExtA No . in szFileName: "F:\MSWPTIME\vo\white"
err:mmio:MMIO_ParseExtA No . in szFileName: "F:\MSWPTIME\vo\flute"
err:mmio:MMIO_ParseExtA No . in szFileName: "F:\MSWPTIME\vo\burgundy"
err:mmio:MMIO_ParseExtA No . in szFileName: "F:\MSWPTIME\vo\bordeaux"

The attached log is for WINEDEBUG=+relay,+int21,+mmio, starting wine.exe,
clicking Ignore for each dialog box, then clicking the above sequence.

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

http://bugs.winehq.org/show_bug.cgi?id=23865

Jerome Leclanche  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Jerome Leclanche  2012-01-13 12:37:48 CST ---
Do you have a download for the program?
Please retest in wine-1.3.36 or newer.

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

http://bugs.winehq.org/show_bug.cgi?id=23865

--- Comment #2 from Mark K  2012-01-13 13:39:06 CST ---
Created attachment 38336
  --> http://bugs.winehq.org/attachment.cgi?id=38336
Partial log

I'm not aware of a freely-available trial/demo.

The bug is still present with Wine 1.3.36, but slightly different. There are no
longer any "err:mmio:MMIO_ParseExtA No . in szFileName:" messages. It looks
like Wine is trying to open the files but failing.

When you mount the CD-ROM in Linux, some files have names ending with a dot,
e.g. "bordeaux."

I couldn't see any option in the mount man page to remove a trailing dot from
filenames. On Windows those files show without the dot character, e.g. just
"BORDEAUX"

What seems to be happening now is that Wine tries to open e.g.
"E:\MSWPTIME\vo\sherry" but that fails. Wine should then try opening
"E:\MSWPTIME\vo\sherry." instead. (Maybe only have that fallback behaviour if
the file is on a CD-ROM?)

Attached is 1000 lines from a log, from the point where the program tries to
open "E:\MSWPTIME\vo\sherry". The relevant part seems to be this:

trace:mmio:MMIO_Open ("E:\MSWPTIME\vo\sherry", (nil), 00010020, unicode);
trace:mmio:MMIO_ParseExtA ("E:\MSWPTIME\vo\sherry")
trace:mmio:MMIO_SetBuffer (0x12d2a0 (nil) 8192 0)
trace:mmio:mmioDosIOProc (0x12d2a0, 3, 0x12d280, 0x0);
0026:Call KERNEL32.OpenFile(0012d280
"E:\MSWPTIME\vo\sherry",007bd584,00000020) ret=7e4428bd
0026:Ret  KERNEL32.OpenFile() retval=ffffffff ret=7e4428bd
trace:mmio:mmioDosIOProc (0x12d2a0, 2, 0x0, 0x1);
0026:Call KERNEL32._llseek(ffffffff,00000000,00000001) ret=7e4427f1
0026:Ret  KERNEL32._llseek() retval=ffffffff ret=7e4427f1

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

http://bugs.winehq.org/show_bug.cgi?id=23865

Michael Mc Donnell  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

http://bugs.winehq.org/show_bug.cgi?id=23865

--- Comment #3 from Michael Mc Donnell  2012-06-12 14:40:38 CDT ---
I have tracked the issue down to openFile in kernel32. It does not support file
names ending in dot. It seems like filenames ending in dot are forbidden on
Windows, but it is still possible to create them, e.g. with "notepad sherry.",
and they can be opened with openFile on Windows.

There was a test patch [1] submitted once but it was never accepted.

[1] http://www.winehq.org/pipermail/wine-patches/2004-May/011036.html

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

http://bugs.winehq.org/show_bug.cgi?id=23865

--- Comment #4 from Michael Mc Donnell  2012-06-21 11:12:12 CDT ---
(In reply to comment #3)
> I have tracked the issue down to openFile in kernel32. It does not support file
> names ending in dot. It seems like filenames ending in dot are forbidden on
> Windows, but it is still possible to create them, e.g. with "notepad sherry.",
> and they can be opened with openFile on Windows.

I'm starting to think that this might not be a problem with OpenFile because
you see them as normal files on Windows without the trailing dot. I can see
files with trailing dots on Windows 7 with an NTFS partition if I create them
myself. Which version of Windows are you using?

Btw I can't create files with trailing dots with notepad anymore. Echo works
fine though:

echo Wine > "\?%USERPROFILE%\sherry."

You can delete it again using the following command:

del "\?%USERPROFILE%\sherry."

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

http://bugs.winehq.org/show_bug.cgi?id=23865

Mark K  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #5 from Mark K  2012-06-21 11:56:46 CDT ---
I was testing with Windows XP.

I think the problem is caused by filenames which with a dot being treated
differently by the Windows CD-ROM (ISO 9660) filesystem compared to the Linux
one.

The Windows ISO 9660 filesystem removes trailing dots from filenames when you
get a directory listing. The Linux ISO 9660 code doesn't. So Wine needs to be
able to handle that.

With MS Wine Guide, it tries to open a file named "sherry" say. If that file
doesn't exist, Wine should try opening "sherry." instead. Doing that should fix
this issue. I guess the Windows ISO 9660 code must be doing something like that
already? (Or perhaps it strips trailing dots from names when reading the
directory, so opening "sherry" in Windows would automatically open "sherry.".)

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

http://bugs.winehq.org/show_bug.cgi?id=23865

--- Comment #6 from Michael Mc Donnell  2012-06-21 14:31:51 CDT ---
(In reply to comment #5)
> I was testing with Windows XP.
>
> I think the problem is caused by filenames which with a dot being treated
> differently by the Windows CD-ROM (ISO 9660) filesystem compared to the Linux
> one.
>
> The Windows ISO 9660 filesystem removes trailing dots from filenames when you
> get a directory listing. The Linux ISO 9660 code doesn't. So Wine needs to be
> able to handle that.
>
> With MS Wine Guide, it tries to open a file named "sherry" say. If that file
> doesn't exist, Wine should try opening "sherry." instead. Doing that should fix
> this issue. I guess the Windows ISO 9660 code must be doing something like that
> already? (Or perhaps it strips trailing dots from names when reading the
> directory, so opening "sherry" in Windows would automatically open "sherry.".)

I think you are right about it being an ISO 9660 issue. That unfortunately
makes it a whole lot more tricky to fix.

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

http://bugs.winehq.org/show_bug.cgi?id=23865

--- Comment #7 from Mark K  2012-06-21 15:10:01 CDT ---
I don't think it would be hard to fix necessarily.

The logic for Wine's file-opening function could go something like this:
 - Try to open the specified filename. If successful, return as usual.
 - If the file could not be opened because it does not exist, check whether the
name is <= 8 chars with no extension. If so, append a dot to the specified name
and try opening that instead. (Maybe only do that fallback if the drive the
file is on is marked as a CD-ROM?)

That may well be sufficient for MS Wine Guide at least.

There might be other programs which e.g. get a listing of files in a CD-ROM
directory, and expect the names to not end in dots. They could get confused if
Wine passes the with-dots filenames directly. In that case Wine should probably
strip trailing dots when returning filenames to the calling program.

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

http://bugs.winehq.org/show_bug.cgi?id=23865

Bruno Jesus  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |[e-mail]
     Ever Confirmed|0                           |1

--- Comment #8 from Bruno Jesus  2013-06-05 18:55:22 CDT ---
I can confirm this issue in wine 1.5.31.

The application really asks for the file without the .
trace:mmio:MMIO_ParseExtA ("G:\MSWPTIME\vo\port")

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

http://bugs.winehq.org/show_bug.cgi?id=23865

--- Comment #9 from Bruno Jesus  2013-06-06 22:27:15 CDT ---
I'm not sure if this is a wine bug anymore... I don't see the dots inside
windows 3.11 or windows XP.

07/08/1995  09:10    <DIR>          .
15/08/1995  12:31    <DIR>          ..
28/01/1995  09:48           136.888 BORDEAUX
28/01/1995  09:48           133.676 BURGUNDY
28/01/1995  09:48            82.410 FLUTE
28/01/1995  09:49           123.796 PORT
28/01/1995  09:50           206.696 RED
05/04/1995  09:00         3.494.956 SCORE
28/01/1995  09:53            91.972 SHERRY
20/01/1995  12:07           705.278 TITLE
28/01/1995  09:41           178.492 TITLE.2
28/01/1995  09:54           108.658 WHITE

When I mount the CD in linux there are dots, when I copy the CD and mount with
mount command there are dots, when I mount with fuseiso there are NO dots...
Could this be a kernel issue regarding the cdrom filesystem?

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

http://bugs.winehq.org/show_bug.cgi?id=23865

--- Comment #10 from Bruno Jesus  2013-06-06 23:33:47 CDT ---
Well, my current conclusion is that this is a kernel bug. The kernel source
code lacks the check for files ending in '.'. It does that for joliet systems
but not for iso9660. FuseISO have that check. But, PC-BSD also has the wrong
behavior... So I'm not sure who is guilty.

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

https://bugs.winehq.org/show_bug.cgi?id=23865

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |UPSTREAM

--- Comment #11 from Austin English  ---
(In reply to Bruno Jesus from comment #10)
> Well, my current conclusion is that this is a kernel bug. The kernel source
> code lacks the check for files ending in '.'. It does that for joliet
> systems but not for iso9660. FuseISO have that check. But, PC-BSD also has
> the wrong behavior... So I'm not sure who is guilty.

UPSTREAM.

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

https://bugs.winehq.org/show_bug.cgi?id=23865

--- Comment #12 from Bruno Jesus  ---
When mounting the CD with cdemu the dots also don't exist, and then the program
runs. So fuseiso and cdemu can be used to circumvent this issue.

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

https://bugs.winehq.org/show_bug.cgi?id=23865

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #13 from Austin English  ---
Closing.

[Bug 23865] Microsoft Wine Guide (16-bit) unable to find files whose names end with .

https://bugs.winehq.org/show_bug.cgi?id=23865

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |RESOLVED

--- Comment #14 from Austin English  ---
This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should
only be closed when fixed upstream.

Setting back to RESOLVED NOTOURBUG.

Sorry for the spam.