Fallout II requires that a certain file is located on a CDROM drive. For some reason it checks this using SetFileAttributes, which is supposed to fail on readonly drives. This used to work until the following patch broke this behaviour (message continues after the patch):
Index: file.c =================================================================== RCS file: /home/wine/wine/win32/file.c,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- file.c 2001/05/14 20:09:39 1.26 +++ file.c 2001/05/18 23:18:25 1.27 @@ -104,7 +104,7 @@ { FILE_SetDosError(); MESSAGE("Wine ERROR: Couldn't set file attributes for existing file "%s". Check permissions or set VFAT "quiet" flag !\n", full_name.long_name); - return FALSE; + return TRUE; } return TRUE; }
The above patch obviously breaks Windows compatibility (and likely has a bug related to FILE_SetDosError). I would like to suggest that this patch is either removed or replaced with a patch that includes a C comment that properly documents reasons for this deliberate incompatibility and that either only affects non-CDROM drives or drives configured using some magic flag in Wine configuration file.
On Sat, Jan 26, 2002 at 06:58:31AM +0200, Jukka Heinonen wrote:
Fallout II requires that a certain file is located on a CDROM drive. For some reason it checks this using SetFileAttributes, which is supposed to fail on readonly drives. This used to work until the following patch broke this behaviour (message continues after the patch):
Index: file.c
RCS file: /home/wine/wine/win32/file.c,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- file.c 2001/05/14 20:09:39 1.26 +++ file.c 2001/05/18 23:18:25 1.27 @@ -104,7 +104,7 @@ { FILE_SetDosError(); MESSAGE("Wine ERROR: Couldn't set file attributes for existing file "%s". Check permissions or set VFAT "quiet" flag !\n", full_name.long_name);
return FALSE;
return TRUE;}
The above patch obviously breaks Windows compatibility (and likely has a bug related to FILE_SetDosError). I would like to suggest that this patch is either removed or replaced with a patch that includes a C comment that properly documents reasons for this deliberate incompatibility and that either only affects non-CDROM drives or drives configured using some magic flag in Wine configuration file.
NO !! :-)
Note that read-only handling in general is *very* problematic. (and Marcus *did* have a reason for changing it the other way around, I suppose !) There is the issue of read-only *drives* vs. read-only *files*, too !
Wine should make sure that it returns proper values in all cases.
Simply reverting the patch done by Marcus does no good at all. Either invest enough time to fully understand read-only file/directory/device behaviour (and possibly fix Wine to handle everything 150% correctly :) or forget it, I'd say.
So either submit a patch that adds a comment to SFA() documenting the reason for the current behaviour and where/why it breaks sometimes, or write a "real" patch correctly fixing it.
On Sat, Jan 26, 2002 at 06:44:12PM +0100, Andreas Mohr wrote:
On Sat, Jan 26, 2002 at 06:58:31AM +0200, Jukka Heinonen wrote:
Fallout II requires that a certain file is located on a CDROM drive. For some reason it checks this using SetFileAttributes, which is supposed to fail on readonly drives. This used to work until the following patch broke this behaviour (message continues after the patch):
Index: file.c
RCS file: /home/wine/wine/win32/file.c,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- file.c 2001/05/14 20:09:39 1.26 +++ file.c 2001/05/18 23:18:25 1.27 @@ -104,7 +104,7 @@ { FILE_SetDosError(); MESSAGE("Wine ERROR: Couldn't set file attributes for existing file "%s". Check permissions or set VFAT "quiet" flag !\n", full_name.long_name);
return FALSE;
return TRUE;}
The above patch obviously breaks Windows compatibility (and likely has a bug related to FILE_SetDosError). I would like to suggest that this patch is either removed or replaced with a patch that includes a C comment that properly documents reasons for this deliberate incompatibility and that either only affects non-CDROM drives or drives configured using some magic flag in Wine configuration file.
NO !! :-)
Note that read-only handling in general is *very* problematic. (and Marcus *did* have a reason for changing it the other way around, I suppose !) There is the issue of read-only *drives* vs. read-only *files*, too !
Wine should make sure that it returns proper values in all cases.
Simply reverting the patch done by Marcus does no good at all. Either invest enough time to fully understand read-only file/directory/device behaviour (and possibly fix Wine to handle everything 150% correctly :) or forget it, I'd say.
The problem is more that file attribute settings just doesnt work that well on VFAT.
So you basically break some more installers.
I don't remember what installer it was however. :(
Ciao, Marcus
On Sat, Jan 26, 2002 at 06:49:53PM +0100, Marcus Meissner wrote:
On Sat, Jan 26, 2002 at 06:44:12PM +0100, Andreas Mohr wrote:
Simply reverting the patch done by Marcus does no good at all. Either invest enough time to fully understand read-only file/directory/device behaviour (and possibly fix Wine to handle everything 150% correctly :) or forget it, I'd say.
The problem is more that file attribute settings just doesnt work that well on VFAT.
So you basically break some more installers.
I don't remember what installer it was however. :(
Hmm, like always ;-) That's why I'm particularly fond of adding program information to Changelogs I create :)
Anyway, the installer shouldn't matter at all. What matters is writing a very good test program to find a way to support every possible combination as well as possible.
On Sat, Jan 26, 2002 at 06:55:52PM +0100, Andreas Mohr wrote:
Anyway, the installer shouldn't matter at all. What matters is writing a very good test program to find a way to support every possible combination as well as possible.
Hmm, I think the solution here would be to simply add a check for a read-only medium at this place and to conditionally return FALSE or TRUE. Just use DRIVE_FindDriveRoot() on full_name.long_name to get the drive, then check its flags for read-only e.g. via DRIVE_GetFlags().
On Sat, Jan 26, 2002 at 06:49:53PM +0100, Marcus Meissner wrote:
The problem is more that file attribute settings just doesnt work that well on VFAT.
So you basically break some more installers.
I don't remember what installer it was however. :(
Marcus, can you give some detailed information about cases where SetFileAttributes must succeed even though chattr fails?
As far as I understand the original reason for your patch to SetFileAttributes was because users in some Wine installation shared large parts of windows and system directories and these shared parts were readonly, which makes chattr and thus SetFileAttributes fail.
Now you are talking about some VFAT related problem. Is this problem in Linux VFAT drivers, Wine VFAT support or VFAT itself? If you can give enough details I could try to make a patch that would make SetFileAttributes behaviour closer to Windows behaviour and which would have proper comments about incompatibilities (unless you want to do the patch yourself, of course).
On Sat, Jan 26, 2002 at 09:57:44PM +0200, Jukka Heinonen wrote:
On Sat, Jan 26, 2002 at 06:49:53PM +0100, Marcus Meissner wrote:
The problem is more that file attribute settings just doesnt work that well on VFAT.
So you basically break some more installers.
I don't remember what installer it was however. :(
Marcus, can you give some detailed information about cases where SetFileAttributes must succeed even though chattr fails?
I am using the following directory setup:
/mnt/hdaX is the 'C' drive of the windows installation, read only mounted vfat.
There is a ~/windows and ~/windows/system directory, which contain symlinks for every .exe and .dll to /mnt/hdaX/windows/ and .../system/.
Now, if I run "aspiinst.exe" I get: Wine ERROR: Couldn't set file attributes for existing file "/home/marcus/windows/system/wnaspi32.dll". Check permissions or set VFAT "quiet" mount flag Wine ERROR: Couldn't set file attributes for existing file "/home/marcus/windows/system/winaspi.dll". Check permissions or set VFAT "quiet" mount flag
It tries to set the permissions through the symlink, which causes this problem.
As far as I understand the original reason for your patch to SetFileAttributes was because users in some Wine installation shared large parts of windows and system directories and these shared parts were readonly, which makes chattr and thus SetFileAttributes fail.
See above.
Now you are talking about some VFAT related problem. Is this problem in Linux VFAT drivers, Wine VFAT support or VFAT itself?
I was a bit confused. However chmod does not work on vfat as far as I can see (chmod returns success only if the set mode is the same as the original one).
Ciao, Marcus
On Sun, Jan 27, 2002 at 09:12:00AM +0100, Marcus Meissner wrote:
I am using the following directory setup:
/mnt/hdaX is the 'C' drive of the windows installation, read only mounted vfat.
There is a ~/windows and ~/windows/system directory, which contain symlinks for every .exe and .dll to /mnt/hdaX/windows/ and .../system/.
Now, if I run "aspiinst.exe" I get: Wine ERROR: Couldn't set file attributes for existing file "/home/marcus/windows/system/wnaspi32.dll". Check permissions or set VFAT "quiet" mount flag Wine ERROR: Couldn't set file attributes for existing file "/home/marcus/windows/system/winaspi.dll". Check permissions or set VFAT "quiet" mount flag
It tries to set the permissions through the symlink, which causes this problem.
This is not surprising since chmod operation is supposed to fail if you have mounted filesystem in readonly mode. Perhaps in this case Wine should indeed fake that operation was succesful, just as it does now.
I was a bit confused. However chmod does not work on vfat as far as I can see (chmod returns success only if the set mode is the same as the original one).
Is this case separate from the above case? I have checked Linux kernel sources (2.4.13 only) and I have found no reason why chmod should fail on read-write mounted VFAT filesystem. Perhaps there is some obscure bug/feature in Linux VFAT driver that escapes my eyes. Could you provide more information about this case, please?
Is this case separate from the above case? I have checked Linux kernel sources (2.4.13 only) and I have found no reason why chmod should fail on read-write mounted VFAT filesystem. Perhaps there is some obscure bug/feature in Linux VFAT driver that escapes my eyes. Could you provide more information about this case, please?
Well, it's easy : it depends of the user you mount your VFAT partition with. Look at this example (on ext2) :
nexus6:~$ ls -l toto -rwxrwxrwx 1 ulmer users 0 Jan 29 20:53 toto nexus6:~$ su otheruser Password: nexus6:/home/ulmer$ ls -l toto -rwxrwxrwx 1 ulmer users 0 Jan 29 20:53 toto nexus6:/home/ulmer$ chmod o-x toto chmod: toto: Operation not permitted
So if like me, you had your VFAT partition mounted R/W for everybody on the system (or for people from a particular group) but with owner = root, you will have the chmod problem (I was bitten by it once while playing Baldur's Gate).
This bug is really painful for multi-user systems... In my case, I fixed it to have the VFAT files mounted with me as the owner :-)
Lionel
-
Andreas Mohr -
Jukka Heinonen -
Lionel Ulmer -
Marcus Meissner