[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

What I want in R^5RS

   I think it would be best to have a mechanism to atomically "grab" a file
   and perform some operation on it (opening, deleting, renaming, etc).  For

     (let ((p (GRAB-FILE "foo"
		(lambda () (open-input-file "foo"))
		(lambda () (error "Sorry, foo is not there")))))
       (write (read p))
       (close-port p))

   Thus, one could define:

     (define (FILE-EXISTS? <filename-string>)
       (GRAB-FILE <filename-string>
	 (lambda () #t)
	 (lambda () #f)))

You are assuming a model of the OS (like Unix in this respect) in
which deleting a file only removes it from the file system, but
processes that have it open continue to have a handle to it.  I don't
know whether any operating system has done this, but I can easily
imagine an OS invalidating all channels open to a deleted file.
Subsequent operations would no longer be valid, and Scheme would have
no way of really grabbing it.  Within the Unix model (especially with
NFS), having a channel open does not guarantee that the next operation
will do what you expected.  For example, another process may truncate
the file behind your back and you will not be able to read, or you
will write into hyperspace.

   I'm sure someone can suggest a better name for GRAB-FILE and perhaps a
   cleaner interface.  Maybe GRAB-FILE can be integrated to OPEN-INPUT-FILE.
   If the file is not there, OPEN-INPUT-FILE would returns #f.  The procedure
   DELETE-FILE would instead be DELETE-PORT... (you would have to open the file
   before deleting it).

   Other suggestions to solve the atomicity problem?

In general, I don't think we should try to solve the
atomicity/interaction with (perhaps distributed) OS problem at the
same time that we are trying to make Scheme more useable.

I don't think you can come up with a workable solution unless you make
strong assumptions about the OS, and I don't think that is a good

I have no problems with FILE-EXISTS?, and think that it will be useful.