[Bug 9258] New: free space is based on dosdevice free space, rather than partition free space
http://bugs.winehq.org/show_bug.cgi?id=9258 Summary: free space is based on dosdevice free space, rather than partition free space Product: Wine Version: 0.9.34. Platform: All OS/Version: All Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-binary AssignedTo: wine-bugs(a)winehq.org ReportedBy: michael.s.gilbert(a)gmail.com wine will return the incorrect amount of free space to applications under certain common scenarios. it appears that the free space is determined by the dosdevice that has the directory that the application is running from. it should be expected that the free space returned would be based on the partition that has the directory that the application is running from instead. let me provide an example to clarify. i've installed steam to /home/user/games, which falls under the z:/ dosdevice, which is a symlink to /. / and /home are on different partions: $ df -h Filesystem Size Used Avail Use% Mounted on /dev/hda3 9.2G 7.9G 914M 90% / /dev/hda6 63G 30G 30G 50% /home i am trying to install half-life2 via steam, which should be fine because i have 30 GiB of free space in /home. however, the steam application says this is not possible because there is only 914 MiB of free space, and the game needs 3.8 GiB total to install. wine is providing the free space for / instead of /home to the application. note that if i install the game to /home/user/.wine/drive_c/steam, then wine correctly returns 30 GiB free space to steam and i can install the application. i believe this is because the drive_c directory appears to be under the c:/ dosdevice, rather than the z:/ dosdevice. this is a solution, but it is far from optimal to be forced into arranging my files in a way that i don't want to. so i think the problem is that wine returns the size of the partition of the dosdevice that apparently has the working directory, rather than the size of the partition that actually has the working directory. i still don't think i've clearly explained this, so if you have questions, please ask. thanks for all the hard work on wine. mike -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9258 Maarten Lankhorst <M.B.Lankhorst(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX --- Comment #1 from Maarten Lankhorst <M.B.Lankhorst(a)gmail.com> 2007-08-11 04:20:29 --- The way free space is calculated on windows uses drive letters, and calculates the free space in that way, that assumption breaks in wine with bugs like these as result. Fixing it is probably impossible.. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9258 --- Comment #2 from Michael Gilbert <michael.s.gilbert(a)gmail.com> 2007-08-11 12:16:08 --- one solution would be for wine to automatically set up a dosdevice for each partition (cap it at 20 partitions max, otherwise we'll run out of drive letters). although i just tried creating a dosdevice for /home/user, and steam now crashes, but this should probably be reported as a different bug. $ cd /home/user/games/steam $ wine steam.exe runs fine $ ln -s /home/user/ "/home/user/.wine/dosdevices/y:" $ wine steam.exe crashes with error "Fatal Error: Could not load module 'bin/vgui2.dll'" what do you think? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9258 Jesse Allen <the3dfxdude(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #3 from Jesse Allen <the3dfxdude(a)gmail.com> 2007-08-11 12:32:48 --- Wine already can create a drive letter per partition from /etc/fstab by going to winecfg and click auto detect in the drives tab. But the problem is easy enough to fix by just creating the one drive letter you need for /home/user -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9258 --- Comment #4 from Michael Gilbert <michael.s.gilbert(a)gmail.com> 2007-08-11 14:36:25 --- wouldn't it make more sense to do the dosdevices autodetection when ~/.wine is first created, rather than through winecfg? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9258 --- Comment #5 from Jesse Allen <the3dfxdude(a)gmail.com> 2007-08-11 14:51:18 --- I would not think so, as the auto detection from /etc/fstab is not always what the user wants. Wine also automatically sets up drive letters from HAL too, so that is already taken care of too. I find what wineprefixcreate does is pretty reasonable. Maybe wine can set up a drive letter for the home directory in wineprefixcreate? But most people install to drive C anyway so it doesn't matter. I don't think there are any pressing concerns here. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9258 Michael Gilbert <michael.s.gilbert(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|WONTFIX | --- Comment #6 from Michael Gilbert <michael.s.gilbert(a)gmail.com> 2007-08-12 01:45:20 --- under what case would the /etc/fstab autodetection not be what the user wants? even if there are cases, then the user can easily use winecfg or remove the symlinks that they do not want. the most important thing is to choose sensible defaults that do the right thing for most users. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9258 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |trivial Status|UNCONFIRMED |RESOLVED OS/Version|All |other Platform|All |Other Resolution| |WORKSFORME --- Comment #7 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2007-08-12 02:05:16 --- I'm not sure how the problem of free space reporting morphed into discussion about what should be mapped. This bug is about improper free space reporting of mapped drives, no matter where the $WINEPREFIX is. All other "bugs" enhancements or discussions about what should Wine do - put into separate bugs. And reading what you did, Wine does _exactly_ what you told it to do. Steam can not install applications _outside_ of where it's been installed. And you said yourself you installed steam into z:\home\user\games. Now you complain that Wine does not report size of the other drive instead of z: ?
so i think the problem is that wine returns the size of the partition of the dosdevice that apparently has the working directory, rather than the size of the partition that actually has the working directory. Not correct. Wine properly reports the size of the partition where you have drive mapped to. Not part of the partition, not all of the partitions under /.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9258 --- Comment #8 from Michael Gilbert <michael.s.gilbert(a)gmail.com> 2007-08-12 02:13:30 ---
And reading what you did, Wine does _exactly_ what you told it to do. Steam can not install applications _outside_ of where it's been installed. And you said yourself you installed steam into z:\home\user\games. Now you complain that Wine does not report size of the other drive instead of z: ?
well, this behavior is just not the way that unix works, but i understand that it is a limitation of implementing a "windows"-like system on unix. the reopen was an accidental click. i am fine with this being closed. i will open new bugs for the other issues i've brought up. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9258 James Hawkins <truiken(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|_obsolete_binary |-unknown -- 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.
http://bugs.winehq.org/show_bug.cgi?id=9258 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #9 from Austin English <austinenglish(a)gmail.com> 2008-09-18 14:54:32 --- Closing WORKSFORME. -- 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.
participants (1)
-
wine-bugs＠winehq.org