[Openmcl-devel] Weblocks-Demo Permission Denied Win32

John Federico johnrico at gmail.com
Sun Jan 10 23:59:00 PST 2010


Thanks again for all of your help on this.  I ended up putting a
band-aid on it for now.  I changed GEN-FILE-NAME in l1-streams.lisp to

(defun gen-file-name (path)
  (let* ((date (file-write-date path))
         (tem-path (merge-pathnames (make-pathname :name
(%integer-to-string date) :type "tem" :defaults nil) path)))
      (when ( not (probe-file tem-path)) (%create-file tem-path
:if-exists nil) (return tem-path))
      (setf (%pathname-name tem-path) (%integer-to-string (setq date
(1+ date)))))))

and rebuilt ccl [I just added (not (probe-file tem-path)) to the when
line].  It isn't an ideal solution, but it let me run the

There may also be an issue in the weblocks code.  The longer I played
with the demo the more and more temp files filled my folder (they all
disappeared when I shut down lisp), and also the more and more open
file streams I had.  After a few minutes, I had 50 or so .tem files
and 50 or so open file streams (to files other than the .tem files) So
there might be something in the weblocks/hunchentoot code keeping all
those open (although, maybe all those file streams are supposed to be
there?).  I think I'll save that one for another day.

Thanks again! -John

On Mon, Jan 11, 2010 at 12:36 AM, Gary Byers <gb at clozure.com> wrote:
> On Sun, 10 Jan 2010, John Federico wrote:
>> On Sun, Jan 10, 2010 at 8:15 PM, Gary Byers <gb at clozure.com> wrote:
>>> (The function CCL:OPEN-FILE-STREAMS returns a list of ... open lisp
>>> file streams; it'd be interesting to see whether or not there's a lisp
>>> stream open on a (deleted) temp file when the error occurs.)
>> I just tried it again and got a similar error.  There are three .tem
>> files sitting in the folder which I can't access:
>> 3472150697.tem
>> 3472154034.tem
>> 3472163064.tem
>> ("/usr/local/asdf-install/site/weblocks-stable/pub/stylesheets/vzn/dataform-import'.0.css"/4244
>> ("/usr/local/asdf-install/site/weblocks-stable/pub/stylesheets/vzn/datagrid-import'.0.css"/4164
>> ("/usr/local/asdf-install/site/weblocks-stable/pub/stylesheets/vzn/dataform-import'.0.css"/4108
>> ISO-8859-1) #x9EF3246>)
>> ?
>> The backtrace from weblocks has this in it:
>> (44380620) : 7 (%CREATE-FILE
>> #P"c:/usr/local/asdf-install/site/weblocks-stable/pub/stylesheets/vzn/3472163064.tem"
>> (44380644) : 8 (GEN-FILE-NAME
>> #P"c:/usr/local/asdf-install/site/weblocks-stable/pub/stylesheets/vzn/pagination'.0'.css.gz")
>> 191
>> (44380658) : 9 (MAKE-FILE-STREAM
>> "/usr/local/asdf-install/site/weblocks-stable/pub/stylesheets/vzn/pagination'.0.css.gz"
>> :PRIVATE T) 999
>> So that must be what is happening.  There is already a temp file there
>> that was marked for deletion, and then it tries to create another one
>> with the same name, giving the error.  Since it has been marked for
>> deletion, then I am assuming that is why I can't access the file
>> through windows explorer.
> The file(s) that're queued for deletion should be deleted as soon as
> the last open handle to them is closed.  (OPEN-FILE-STREAMS) seems
> to indicate that no lisp file stream references any of the temporary
> files, so I wonder what else might have an open handle to any of
> these files.
>> Is it possible to override GEN-FILE-NAME in ccl-init.lisp, and add an
>> extra condition to test for "Permission Denied"?
> You could aproximate the truth by checking to see if you get a
> permission error in %CREATE-FILE when :IF-EXISTS is NIL and PROBE-FILE
> says that the file exists.  (You don't really know if the file was
> created - perhaps by some other program running with different
> permissions - at some instant right after the attempt to create it
> failed, and you don't really know whether the permission error has to
> do with this case - a partially-deleted file - or with directory
> permissions, but you do know that the file exsited at about the time
> that we tried to create it with :IF-EXISTS NIL and you know that it
> wasn't successfully created by this call to %CREATE-FILE, so returning
> NIL in that case isn't totally inappropriate.)
> I'd still like to know what's holding on to an open handle to the temp
> file; I don't think that the lisp ever opens streams to these files,
> so it seems like something in the lisp runtime/the little bit of C
> library that we use/Windows itself that's neglecting to close a
> handle.  If user code deletes and tries to recreate a file while an
> open file stream still references the file, we can say "that doesn't
> work on Windows, so don't do that"; if this just happens sometimes as
> part of the :IF-EXISTS :SUPERSEDE mechanism, we can't really say
> "don't use :IF-EXISTS :SUPERSEDE" ...
>> Thank you very much for all the help thus far.  -John
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list