[AC21.4] Fix handling of the read-only attribute bit - Oops!

[Vin Shelton]

Oops - this patch:

On 1/1/07, Vin Shelton <acs at xemacs.org> wrote:
> APPROVE COMMIT 21.4.
>
> Thanks for the patch, Benson.  I've applied it to the 21.4 branch; it
> will appear in XEmacs 21.4.21.
>
> (The patch as originally posted was malformed - I've included it here
> for reference.)
>
> Index: src/ChangeLog
> ===================================================================
> RCS file: /pack/xemacscvs/XEmacs/xemacs/src/ChangeLog,v
> retrieving revision 1.290.2.116
> diff -a -u -u -0 -r1.290.2.116 ChangeLog
> --- src/ChangeLog       2006/12/10 00:14:52     1.290.2.116
> +++ src/ChangeLog       2007/01/02 00:16:10
> @@ -0,0 +1,7 @@
> +2006-12-25  Benson I. Margulies  <benson at dchbk.us>
> +
> +       * src/fileio.c (check_writable):
> +        Cope with the fact that the read-only attribute trumps Windows NTFS
> +        ACLS.
> +
> +
> Index: src/fileio.c
> ===================================================================
> RCS file: /pack/xemacscvs/XEmacs/xemacs/src/fileio.c,v
> retrieving revision 1.66.2.8
> diff -a -u -r1.66.2.8 fileio.c
> --- src/fileio.c        2006/11/20 18:20:22     1.66.2.8
> +++ src/fileio.c        2007/01/02 00:16:19
> @@ -2307,13 +2307,17 @@
>    filename = filename_buffer;
>  #endif
>
> +  // ask simple question first
> +  attributes = GetFileAttributes(filename);
> +  if (0 != (attributes & FILE_ATTRIBUTE_READONLY))
> +      return 0;
> +
>    /* Win32 prototype lacks const. */
>    error = GetNamedSecurityInfo((LPTSTR)filename, SE_FILE_OBJECT,
>                                 DACL_SECURITY_INFORMATION|GROUP_SECURITY_INFORMATION|OWNER_SECURITY_INFORMATION,
>                                 &psidOwner, &psidGroup, &pDacl, &pSacl, &pDesc);
>    if (error != ERROR_SUCCESS) { // FAT?
> -    attributes = GetFileAttributes(filename);
> -    return (attributes & FILE_ATTRIBUTE_DIRECTORY) || (0 == (attributes & FILE_ATTRIBUTE_READONLY));
> +      return 1;
>    }
>
>    genericMapping.GenericRead = FILE_GENERIC_READ;
>

actually makes things worse on my system.  Here's what I see:

$ ls -ld Documents Documents/foo
ls: cannot access Documents/foo: No such file or directory
dr-xr-xr-x+ 22 vshelton Domain Users 0 Jan  3 09:01 Documents

$ xemacs Documents/foo

yields the late unlamented "File not found and directory
write-protected" message.  (I observed this behavior under cygwin, but
the native windows build exhibits the same behavior.)

Benson, is it possible I screwed up the patch?  Can you please investigate?

Even worse: "xemacs -vanilla Documents/foo" puts xemacs into an
interruptible loop attempting to update the display.  I will examine
this case further.

Thanks,
  Vin