https://bugs.winehq.org/show_bug.cgi?id=43240
Bug ID: 43240 Summary: Java 8 believes the filesystem is read-only Product: Wine Version: 2.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs@winehq.org Reporter: taho@dnsdeer.com Distribution: ---
Created attachment 58546 --> https://bugs.winehq.org/attachment.cgi?id=58546 A Java sample program
Symptom: Calls to java.nio.file.Files.isWritable() always return false, even though the specified file is very definitely writable – the same Java program running under Linux correctly returns true for the same file.
Software versions: Arch Linux (x86-64) Wine 2.10 Java 1.8.0_131-b11
Cause: Files.isWritable ends up calling sun.nio.fs.WindowsFileSystemProvider.checkAccess, which via WindowsFileStore.create calls the WindowsFileStore constructor. In those WindowsFileStore methods, the Win32 API function GetVolumePathName is called and its result passed to GetVolumeInformation – which is where the bug is.
In my case, I'm passing in the filename "Z:\tmp\winebugtest\winebugtest.java", where Z: is the Linux root directory. Because /tmp is a separate filesystem, the call to GetVolumePathName returns "Z:\tmp". So far so good. But when this is passed to GetVolumeInformation, it figures there are too many backslashes and returns an error. This results in a Java IOException which ends up causing isWritable to return false.
If I create a T: drive pointing to /tmp (through winecfg) everything works correctly – GetVolumePathName resolves "T:\winebugtest\winebugtest.java" to "T:", GetVolumeInformation is happy and Java gets the correct result.
The Wine implementation of GetVolumeInformation in kernel32/volume.c has the comment "there must be exactly one backslash in the name, at the end".
Microsoft's documentation, I think, disagrees: https://msdn.microsoft.com/en-us/library/windows/desktop/aa364993(v=vs.85).a...
I have attached the relevant portions of the logs (from WINEDEBUG='+relay') and a sample program.
https://bugs.winehq.org/show_bug.cgi?id=43240
--- Comment #1 from taho@dnsdeer.com --- Created attachment 58547 --> https://bugs.winehq.org/attachment.cgi?id=58547 Excerpts from Wine logs
https://bugs.winehq.org/show_bug.cgi?id=43240
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
https://bugs.winehq.org/show_bug.cgi?id=43240
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=43240
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |damjan.jov@gmail.com Status|UNCONFIRMED |NEW
--- Comment #2 from Damjan Jovanovic damjan.jov@gmail.com --- Wine 4.12.1
There's definitely a bug here somewhere, but I need to compare results with Windows to see exactly where. Wine's unit tests already prove the trailing backslash behavior. Is some prior Windows API call returning a backslash on Windows but not on Wine?
https://bugs.winehq.org/show_bug.cgi?id=43240
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
--- Comment #3 from Damjan Jovanovic damjan.jov@gmail.com --- Still a bug in Wine 7.1.
The proximal cause is in dlls/kernelbase/volume.c function GetVolumeInformationW().
When there is no Wine drive mapping for the *nix mountpoint, the volume's root directory will be a compound path with multiple backslashes, eg. Z:\tmp\ in your case. The nt_name in that function becomes \??\Z:\tmp\. The i variable stops at the end of "\??\Z:\", ignoring the "tmp\" suffix. The check for i being at the end of the string fails, and since the string contains a 2nd backslash, the function fails early with: SetLastError( ERROR_DIR_NOT_ROOT ); eventually leading to java.nio.file.Files.isWritable() returning false.
Under dlls/kernel32/tests/volume.c function test_GetVolumeInformationA() we see how ERROR_DIR_NOT_ROOT is expected even on "C:\Windows\".
But where is the root cause? 1. Should GetVolumePathName() return Z:\ instead of Z:\tmp, since Z:\tmp is not a mapped drive, so that GetVolumeInformation() gets called with Z:\ and works? 2. Should GetVolumeInformation() detect non-root paths differently? I think Windows allows mounting without allocating a driver letter, does it allow the mountpoint's long path to be passed to GetVolumeInformation() then? 3. Is the current behaviour already the best we can do, ie. should *nix mountpoints without corresponding drive mapping in Wine be semi-visible and semi-functional to Windows applications like they are now?
-
wine-bugs＠winehq.org -
WineHQ Bugzilla