[Ecls-list] interactive rename-file was open :supersede and rename-file advise

[Geo Carncross]

On Nov 28, 2007 4:46 PM, Juan Jose Garcia-Ripoll
<jjgarcia at users.sourceforge.net> wrote:
> On Nov 27, 2007 5:10 PM, Geo Carncross <geocar at gmail.com> wrote:
> > Included is a new patch to rename-file. This one is interactive and
> > helps outline the semantics that I propose be added to open with
> > :RENAME-AND-DELETE
>
> This seems like a noncritical fix with interesting functionality, not
> only on the rename part, but also for adding continuations. I am
> currently abroad, but I would definitely like to incorporate your
> patches when I come back and find time for testing. The only thing
> remaining is...

Wonderful.

As an aside: It's non-critical in the sense that I can get access to
the functionality using FFI, or in the manner of implementation, but
it's not possible to write crashproof programs on unix without a
RENAME-THAT-CLOBBERS and a RENAME-THAT-DOESNT-CLOBBER so I'm trying to
find a way to introduce them that is inconspicuous.

If this isn't the right way to go, let me know and I'll make it right.


> > If this patch is accepted, I'd like to then modify OPEN to be
> > crashproof when given :IF-EXISTS :RENAME-AND-DELETE by using
> > cl_rename_file() to get these same capabilities.
>
> ...where to put the improved options to OPEN. I have been reading the
> Lisp Machine manual and they did have the :supersede action as
> expected: create a new file and only replace the old one at the end
> http://common-lisp.net/project/bknr/static/lmman/files.xml#Opening%20and%20Closing%20File%20Streams-section
> They also had :truncate, by the way, which is what most
> implementations now do with :supersede
>
> So what I would recommend is to use a new keyword option such as
> :real-supersede or :delayed-supersede, so that :rename-and-delete can
> be still used with the intended functionality (i.e. rename and move to
> the Trash) on platforms where this is feasible (Windows, Mac OS X).

If we're inventing a new keyword to do it, why not :atomic-replace ?

I'd personally prefer :supersede and :truncate work like lispm which
is what I think Richard suggested. I think it adds robustness to
existing applications and I'm still not convinced there'd be any
breakage.

BTW, are you planning on having DELETE-FILE move files to the trash?