[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@winehq.org ReportedBy: michael.s.gilbert@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
http://bugs.winehq.org/show_bug.cgi?id=9258
Maarten Lankhorst M.B.Lankhorst@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX
--- Comment #1 from Maarten Lankhorst M.B.Lankhorst@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..
http://bugs.winehq.org/show_bug.cgi?id=9258
--- Comment #2 from Michael Gilbert michael.s.gilbert@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?
http://bugs.winehq.org/show_bug.cgi?id=9258
Jesse Allen the3dfxdude@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #3 from Jesse Allen the3dfxdude@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
http://bugs.winehq.org/show_bug.cgi?id=9258
--- Comment #4 from Michael Gilbert michael.s.gilbert@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?
http://bugs.winehq.org/show_bug.cgi?id=9258
--- Comment #5 from Jesse Allen the3dfxdude@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.
http://bugs.winehq.org/show_bug.cgi?id=9258
Michael Gilbert michael.s.gilbert@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|WONTFIX |
--- Comment #6 from Michael Gilbert michael.s.gilbert@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.
http://bugs.winehq.org/show_bug.cgi?id=9258
Vitaliy Margolen vitaliy@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@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 /.
http://bugs.winehq.org/show_bug.cgi?id=9258
--- Comment #8 from Michael Gilbert michael.s.gilbert@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.
http://bugs.winehq.org/show_bug.cgi?id=9258
James Hawkins truiken@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|_obsolete_binary |-unknown
http://bugs.winehq.org/show_bug.cgi?id=9258
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Austin English austinenglish@gmail.com 2008-09-18 14:54:32 --- Closing WORKSFORME.
-
wine-bugs＠winehq.org