http://bugs.winehq.org/show_bug.cgi?id=9158 --- Comment #29 from Anastasius Focht <focht(a)gmx.net> 2009-12-28 17:49:01 --- Hello, --- quote --- I implemented support for the hidden bit along with the fix for bug 15679), but it doesn't seem to fix this. In my testing of FindFirstFile etc. on vista, it seems that layer is not supposed to obey the hidden attribute; even on Vista, FindFirstFile will happily return hidden files to the caller. --- quote --- Returning/preserving FILE_ATTRIBUTE_HIDDEN using xattr is completely fine and the behaviour we want in Wine. Maybe you misunderstood my earlier analysis: --- quote myself --- Because wine doesn't support "native" FILE_ATTRIBUTE_HIDDEN this flag is omitted in the returned WIN32_FIND_DATA.dwFileAttributes (filename doesn't use leading dot "hack" because the installer has no knowledge on this unixism). See dlls/ntdll/directory.c:NtQueryDirectoryFile "dotfiles" code. Hence the special $shtdwn$.req file gets included in file copy list which fails because of sharing violation (remember: it's not supposed to be copied). --- quote myself --- The installer filters out any files/directories with FILE_ATTRIBUTE_HIDDEN (0x2) and FILE_ATTRIBUTE_DIRECTORY (0x10) attributes set in its FindNextFile() loop. I don't know why it still doesn't work for you. When the error message box shows up can you change to temp extraction folder (in WINEPREFIX "c:\<temp-folder-id>") in separate shell and execute: $ getfattr "\$shtdwn\$.req It should have user attrs set. If not, make sure the mount point where you WINEPREFIX lives really has xattrs (user_xattr) enabled. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.