[Openmcl-devel] CCL on 32 bit Windows - write permissions needed to load

[Gary Byers]

On Tue, 13 Oct 2009, harshrc wrote:

> I run 32 bit Windows Vista. I got the copy of CCL from release svn trunk.
>
> I am getting a strange error which I cant reproduce on a linux machine :
>
> here is the output from CMD.exe
>
> C:\Users\harshrc\tools\ccl>wx86cl.exe
> Welcome to Clozure Common Lisp Version 1.3-r11936  (WindowsX8632)!
> ? (load "ok1.lsp")
>> Error: Permission denied : #P"C:/Users/harshrc/tools/ccl/ok1.lsp"
>> While executing: CCL::MAKE-FILE-STREAM, in process listener(1).
>> Type :POP to abort, :R for a list of available restarts.
>> Type :? for other options.
> 1 >
>
> where ok1.lsp is a dummy lisp file containing a single form (+ 1 2)
> C:\Users\harshrc\tools\ccl>cat ok1.lsp
> (+ 1 2)
>
> ok2.lsp is a similar dummy lisp file with same contents as ok1.lsp
>
> C:\Users\harshrc\tools\ccl>wx86cl.exe
> Welcome to Clozure Common Lisp Version 1.3-r11936  (WindowsX8632)!
> ? (load "ok2.lsp")
> #P"C:/Users/harshrc/tools/ccl/ok2.lsp"
> ?
>
> So ok2.lsp loads fine.
> If i look at permissions:
> C:\Users\harshrc\tools\ccl>ls -l ok*
> - -r--r--r-- 1 harshrc Administrators    9 Oct 13 20:04 ok1.lsp
> - -r--r--r-- 1 harshrc Administrators    9 Oct 13 20:39 ok2.lsp
>
> It says no difference, but CMD.exe is buggy I presume, because actual
> permissions set
> from GUI(right click -> properties -> security -> edit permissions)
> for user harshrc are deny write for ok1.lsp and full-control for ok2.lsp.
> i.e. ok1.lsp is not writable and ok2.lsp is writable.

You're apparently running a number of unix-like utilities and have reason
to question the results that they return.  Why this means that "cmd.exe
is buggy" is unclear to me.

>
> Which means Clozure Common Lisp cannot load read-only lisp files on
> Windows?

Or something else is going on.  Since CCL can load read-only files on
Windows (try it yourself: remove write permission from ok2.lsp, then load
the file), "something else" seems like a better explanation.

One possible version of "something else" is that although you have
permission to read the file's data, you don't have permission to
write the file's attributes.  (For reasons that aren't entirely
clear at the moment, CCL's OPEN function wants to be able to
change the attributes of a file opened in readonly mode; that
may have simplified porting some Unix code, but it may not be
reasonable to assume that a Windows user with read access to the
file's data has write access to the file's attributes.)

I think that the "cacls" program provides one way of querying (and
possibly changing) permissions like "FILE_WRITE_ATTRIBUTES".

A less plausible explanation is that the problem that you're seeing
has to do with sharing: if some process has the file open in some
exclusive mode, that may prevent other processes from opening that
file.  That wouldn't explain why the 'cat' program could open the
file if it was trying to do so in that environment.



>
> I wanted to ask wether this happens only for VISTA, or is it the same for XP
> and 2000?
> Or is it just that I compiled CCL in a non-standard way, which seems not
> plausible, since my copy of CCL is from the CCL svn repository.
>

If there's anything unusual about the file that doesn't load, it's not likely
to be OS-version dependent.  I suspect that OPEN's insistence on having
FILE_WRITE_ATTRIBUTES permission to a readonly file is misguided and that the
unusual thing about that file and your situation is that you don't have that
permission.

If you can rebuild the lisp kernel (have a gcc-based toolchain installed),
you can try changing some code near the start of the function lisp_open()
in ccl/lisp-kernel/windows-calls.c:


--- windows-calls.c	(revision 13018)
+++ windows-calls.c	(working copy)
@@ -193,14 +193,11 @@
    dwShareMode = FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE;

    if ((flag & _O_WRONLY) == _O_WRONLY) {
-    dwDesiredAccess |= GENERIC_WRITE | FILE_WRITE_DATA |
-      FILE_READ_ATTRIBUTES | FILE_WRITE_ATTRIBUTES;
+    dwDesiredAccess |= GENERIC_WRITE;
    } else if ((flag & _O_RDWR) == _O_RDWR) {
-    dwDesiredAccess |= GENERIC_WRITE|GENERIC_READ | FILE_READ_DATA |
-      FILE_WRITE_DATA | FILE_READ_ATTRIBUTES | FILE_WRITE_ATTRIBUTES;
+    dwDesiredAccess |= GENERIC_WRITE|GENERIC_READ;
    } else {
-    dwDesiredAccess |= GENERIC_READ | FILE_READ_DATA | FILE_READ_ATTRIBUTES |
-      FILE_WRITE_ATTRIBUTES;
+    dwDesiredAccess |= GENERIC_READ;
    }

e.g., to set "dwDesiredAccess" to one of GENERIC_READ, GENERIC_WRITE, or
GENERIC_READ|GZENERIC_WRITE; the other flags are either redundant or
questionable.

I've done that locally and nothing seems to break; I haven't tried removing
FILE_WRITE_ATTRIBUTES permission from a file to see if that change affects
my ability to open it for reading/load it, but it'd be interesting to see
if that solves the problem in your case.

> Any help would be most appreciated.
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>