[Bug: 21.4.20] Network Drives

[Vin Shelton]

A non-text attachment was scrubbed...
Name: 214.patch
Type: text/x-diff
Size: 2134 bytes
Desc: 21.4 executable suffixes patch
Url : http://lists.xemacs.org/pipermail/xemacs-beta/attachments/20070429/72971bb0/214.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 215.patch
Type: text/x-diff
Size: 1828 bytes
Desc: 21.5 executable suffixes patch
Url : http://lists.xemacs.org/pipermail/xemacs-beta/attachments/20070429/72971bb0/215.bin
-------------- next part --------------
"Steve Higham" <steve at sjlt.co.uk> writes:

> Vin, Stephen,
>
> I'm sorry if I've missed something here, but I cannot think of any
> benefit from trying to identify whether a file is executable under
> windows. Surely the sensible approach it to try and execute it if
> requested, and report any resulting failures.
>
> I appreciate that the Unix approach of having an "executable
> attribute" has benefits. Furthermore programs like xemacs should
> obviously respect this attribute. However windows does not have this
> attribute. The OS shell and all other systems, assume that all files
> are executable.
>
> I can see no end of problems with this proposed function. Where the
> function successfully identifies an executable file there will be no
> benefit. Where the function fails to recognise a file as executable,
> the user will presumably be told that his / her file is not marked
> as executable. This will presumably cause loads of grief and no
> benefit.
>

This afternoon I coded up 21.4 and 21.5 versions of a patch to check
the PATHEXT environment variable in mswindows_is_executable().  Those
patches are attached, largely for reference purposes.  The patches
correct the existing XEmacs brain-damage where it thinks only .BAT,
.COM, .EXE and .CMD are valid executable suffixes.

On thinking it over, I've come to the conclusion that I think that
Steve Higham is right.  Checking for executable access on windows is
fundamentally wrong.

Steve, try this simple patch to see if it gets past the access
problems on building a debug build with MSVC 2005:

--- src/nt.c~	2007-04-29 21:31:57.000000000 -0400
+++ src/nt.c	2007-04-29 21:37:18.734375000 -0400
@@ -1642,18 +1642,7 @@
   else
     permission = _S_IREAD | _S_IWRITE;
   
-  if (wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
-    permission |= _S_IEXEC;
-  else
-    {
-      char * p = strrchr (name, '.');
-      if (p != NULL &&
-	  (stricmp (p, ".exe") == 0 ||
-	   stricmp (p, ".com") == 0 ||
-	   stricmp (p, ".bat") == 0 ||
-	   stricmp (p, ".cmd") == 0))
-	permission |= _S_IEXEC;
-    }
+  permission |= _S_IEXEC;
 
   buf->st_mode |= permission | (permission >> 3) | (permission >> 6);
 
Steve - please let me know how this works for you.  I'm very
interested in fixing the problems you're seeing with your network
drives, so I hope this helps you make progress.

Thanks,
  Vin