Patch that broke SetFileAttributes

[Andreas Mohr]

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;
>      }
>      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.

-- 
Andreas Mohr                        Stauferstr. 6, D-71272 Renningen, Germany
Tel. +49 7159 800604                http://home.nexgo.de/andi.mohr/