[Bug 43240] New: Java 8 believes the filesystem is read-only
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(a)winehq.org Reporter: taho(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43240 --- Comment #1 from taho(a)dnsdeer.com --- Created attachment 58547 --> https://bugs.winehq.org/attachment.cgi?id=58547 Excerpts from Wine logs -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43240 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43240 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43240 Damjan Jovanovic <damjan.jov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |damjan.jov(a)gmail.com Status|UNCONFIRMED |NEW --- Comment #2 from Damjan Jovanovic <damjan.jov(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43240 Damjan Jovanovic <damjan.jov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase --- Comment #3 from Damjan Jovanovic <damjan.jov(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla