http://bugs.winehq.org/show_bug.cgi?id=17776
Summary: Installing on Fat32 partitions seems to be impossible nowadays Product: Wine Version: 1.1.17 Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msi AssignedTo: wine-bugs@winehq.org ReportedBy: een_meel_of_geen_meel@hotmail.com
recently (for about 20 or so versions), I haven't been able to install programs on FAT32 partitions anymore. I still use these on quite a few occasions and dislike having to install them onto my /home partition or whatever. Installation starts fine, but bugs out with an error about not being permitted to write there.
games include but are not limited to: anno 1503, civ4, titan quest
http://bugs.winehq.org/show_bug.cgi?id=17776
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|msi |-unknown Platform|All |Other
--- Comment #1 from Vitaliy Margolen vitaliy@kievinfo.com 2009-03-17 20:48:38 --- Terminal output? If this worked before, please do a regression testing.
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #2 from Austin English austinenglish@gmail.com 2009-03-22 12:15:57 --- Are you trying to change your c drive to a fat32 partition? Or is the drive mounted somewhere and you're trying to install to that drive?
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #3 from Richard Hendrikse een_meel_of_geen_meel@hotmail.com 2009-03-31 12:54:36 --- it's the latter, I'm trying to install a program to another partition, which just happens to be a FAT32 partition.
Hmmm, I thought it'd always be failing, but The Longest Journey, at least, got through the first disc.
All recent games (last ~5 and more years) fail to install, however. A good example is "Civilization 4". If I attempt to install it, I get a "Feature Transfer Error". DefaultFeature/ file is binkw32.dll and the error message is: "Access denied". The file itself, however, was completely copied as well as the file "Readme.htm" and the date shown is in october 2005 for both.
the standard terminal-output is: fixme:storage:StgCreateDocfile Storage share mode not implemented. fixme:reg:GetNativeSystemInfo (0x330db4) using GetSystemInfo() fixme:richedit:ME_HandleMessage WM_STYLECHANGING: stub fixme:richedit:ME_HandleMessage WM_STYLECHANGED: stub err:richedit:ReadStyleSheet ReadStyleSheet: skipping optional destination err:richedit:ReadStyleSheet ReadStyleSheet: skipping optional destination err:richedit:ReadStyleSheet ReadStyleSheet: skipping optional destination fixme:richedit:ME_HandleMessage WM_STYLECHANGING: stub fixme:richedit:ME_HandleMessage WM_STYLECHANGED: stub fixme:shell:IShellLinkA_fnGetPath (0x1c77c00): WIN32_FIND_DATA is not yet filled. fixme:shell:IShellLinkA_fnGetPath (0x1c77c00): WIN32_FIND_DATA is not yet filled. fixme:shell:IShellLinkA_fnGetPath (0x1c77928): WIN32_FIND_DATA is not yet filled. fixme:shell:IShellLinkA_fnGetPath (0x1c77928): WIN32_FIND_DATA is not yet filled. err:ole:dispatch_rpc no apartment found for ipid {ffffffff-ffff-ffff-1b00-000018000000} err:rpc:I_RpcReceive we got fault packet with status 0x80010108 err:ole:dispatch_rpc no apartment found for ipid {ffffffff-ffff-ffff-1b00-000018000000} err:rpc:I_RpcReceive we got fault packet with status 0x80010108 fixme:shell:DllCanUnloadNow stub fixme:shell:DllCanUnloadNow stub fixme:shell:DllCanUnloadNow stub
I'm uncertain about what to do next, since a WINEDEBUG=+all kinda generates too much information and makes stuff not work.
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #4 from Jeff Zaroyko jeffz@jeffz.name 2009-03-31 18:03:24 --- (In reply to comment #3)
it's the latter, I'm trying to install a program to another partition, which just happens to be a FAT32 partition.
I'm uncertain about what to do next, since a WINEDEBUG=+all kinda generates too much information and makes stuff not work.
If you think Wine is to blame, find the last known version of Wine that successfully installs your programs to fat32 then run a regression test. http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #5 from Richard Hendrikse een_meel_of_geen_meel@hotmail.com 2009-04-06 14:26:15 --- Actually, I don't think those wine versions still build, if there are any. The point is, that on windows, Games install fine to FAT32 partitions. Also, there are plenty of older games that *should* install fine to FAT32 (one example is The Longest Journey. I'll try to install other games as well). On WINE, the newer installers don't seem to work with WINE. I wonder if this is due to failing timeschmod, or rather something else.
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #6 from Austin English austinenglish@gmail.com 2009-04-06 16:25:04 --- (In reply to comment #5)
Actually, I don't think those wine versions still build, if there are any.
http://wiki.winehq.org/ReverseRegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=17776
Ben Anderson roothorick@new.rr.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roothorick@new.rr.com
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #7 from Ben Anderson roothorick@new.rr.com 2009-05-06 14:28:34 --- *** Bug 18359 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #8 from Ben Anderson roothorick@new.rr.com 2009-05-06 19:41:41 --- Twelve Sky (http://12-sky.aeriagames.com/) exhibits this problem.
Based on a discussion in freenode #winehq, I'm now fairly confident that this is NOT a regression in Wine, but a regression in the Linux kernel FAT support. It looks like a regression in Wine because with an earlier Wine in an earlier kernel it worked, but not now. As early as 1.1.5 are showing this bug. Easy test -- what kernel were you running when it worked? Try using 1.1.20 under that kernel, see what happens.
Specfically -- and this is a guess -- I think stat() is returning different values for files not yet committed to disk. IShield sees this, and assumes it's being silently denied access to certain features when in fact what it wanted actually happened, it's just being hidden due to this bug. A workaround would be to sync() before stat() calls, but that will have a SEVERE impact on performance.
I'm gonna try NTFS via NTFS-3G, see if it happens there. If not, I'm switching.
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #9 from Ben Anderson roothorick@new.rr.com 2009-05-06 20:37:58 --- It breaks on NTFS-3G, but in a slightly different way that's relevant. On an NTFS volume, even if the running user has the appropriate permissions, the files are never created. You get the access denied error and nothing is made. Compare to Linux FAT module, where the file shows up but errors happen.
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #10 from Richard Hendrikse een_meel_of_geen_meel@hotmail.com 2009-05-07 13:23:54 --- well, yeah, it's been around for a while. iirc, Civilization 4 has been failing to install AFTER copying 1 or more files, stating that it's access was denied, since as early as wine-0.9.40. This is why I haven't shown very much inclination towards performing a regression test...
And your expanation would also tell us why older games might succeed in installing; simply because their installer-versions didn't perform all these checks yet...
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #11 from Austin English austinenglish@gmail.com 2009-11-19 12:53:11 --- This is your friendly reminder that there has been no bug activity for 6 months. Is this still an issue in current (1.1.33 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #12 from Ben Anderson roothorick@new.rr.com 2009-11-24 22:55:49 --- Confirmed still present in 1.1.33 with 12 Sky on NTFS-3G.
http://bugs.winehq.org/show_bug.cgi?id=17776
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
http://bugs.winehq.org/show_bug.cgi?id=17776
Ben Peddell klightspeed@netspace.net.au changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |klightspeed@netspace.net.au
--- Comment #13 from Ben Peddell klightspeed@netspace.net.au 2009-12-19 11:30:37 --- (In reply to comment #12)
Confirmed still present in 1.1.33 with 12 Sky on NTFS-3G.
Does the error occur when the user running wine is set as the owner of the filesystem using the uid=<uid> option to the mount?
If the error still occurs, then the program is probably re-reading the permissions, and reporting failure when they don't match.
Under Windows, when a filesystem is incapable of storing or retrieving security descriptors, it returns STATUS_INVALID_DEVICE_REQUEST. Making Wine do the same when the underlying filesystem is incapable of storing the file mode (e.g. vfat or non-advanced ntfs-3g) should fix this bug.
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #14 from Ben Anderson roothorick@new.rr.com 2009-12-19 14:05:38 --- You found something. If I mount my NTFS partition like this:
mount -t ntfs-3g -o uid=1000,gid=100 /dev/sda4 /mnt/local
Then 12 Sky installs successfully. So at least, we have a workaround.
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #15 from Austin English austinenglish@gmail.com 2010-12-23 18:28:15 CST --- This is your friendly reminder that there has been no bug activity for a year. Is this still an issue in current (1.3.9 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=17776
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #16 from joaopa jeremielapuree@yahoo.fr 2011-04-24 19:14:27 CDT --- No answer in 1 year an dhalf. This bug could be closed as ABANDONED.
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #17 from joaopa jeremielapuree@yahoo.fr 2011-04-24 19:16:23 CDT --- No answer in 1 year an dhalf. This bug could be closed as ABANDONED.
http://bugs.winehq.org/show_bug.cgi?id=17776
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |ABANDONED
--- Comment #18 from Austin English austinenglish@gmail.com 2011-04-25 10:42:31 CDT --- Abandoned.
http://bugs.winehq.org/show_bug.cgi?id=17776
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Austin English austinenglish@gmail.com 2011-04-25 10:53:11 CDT --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=17776
TesX tesfabpel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tesfabpel@gmail.com
--- Comment #20 from TesX tesfabpel@gmail.com 2013-06-20 06:22:04 CDT --- Please reopen this bug... It's still there with Wine 1.5+
<quote> Specfically -- and this is a guess -- I think stat() is returning different values for files not yet committed to disk. IShield sees this, and assumes it's being silently denied access to certain features when in fact what it wanted actually happened, it's just being hidden due to this bug. </quote>
The solution then should be (IMHO) to implement a wrapper for the equivalent of stat() in Windows that takes into account these differences and returns what Windows' apps expect to get...
http://bugs.winehq.org/show_bug.cgi?id=17776
--- Comment #21 from Austin English austinenglish@gmail.com 2013-06-20 16:45:13 CDT --- (In reply to comment #20)
Please reopen this bug... It's still there with Wine 1.5+
<quote> Specfically -- and this is a guess -- I think stat() is returning different values for files not yet committed to disk. IShield sees this, and assumes it's being silently denied access to certain features when in fact what it wanted actually happened, it's just being hidden due to this bug. </quote>
The solution then should be (IMHO) to implement a wrapper for the equivalent of stat() in Windows that takes into account these differences and returns what Windows' apps expect to get...
Please file a new bug (and include an example application that installs on ext4 but not fat32, preferably something that others can download).