Issue CLOSE-FILE-OPENED-WITH-SUPERSEDE
Issue: CLOSE-FILE-OPENED-WITH-SUPERSEDE

Forum: Editorial

References: CLOSE, OPEN

Category: CLARIFICATION/CHANGE

Edit history:
2004-07-20, Version 1 by Bruno Haible
2006-04-13, SBCL implementation note by Nikodemus Siivola

Status: For CLiki consideration

Problem Description:

Clarify the behaviour of :(CLHS CLOSE) when :abort is T and an old file is being superseded: :(CLHS OPEN) implies that an implementation is allowed to have already deleted the old file, whereas :(CLHS CLOSE) does not allow this.

Proposal (CLOSE-FILE-OPENED-WITH-SUPERSEDE:ALLOW):

In the description of CLOSE, add "if possible" before "the file is deleted and any previously existing file is not superseded."

Test case:

Rationale:

The description of the IF-EXISTS modes was written with a more complex filesystem than Unix in mind (1. versions and 2. the distinction between delete and expunge). So any mapping to Unix filesystems must necessarily do some simplifications. It is good that ANSI CL leaves the precise mapping up to the implementation. The description of OPEN's :SUPERSEDE already says "If possible".

Current practice:

CLISP implements :SUPERSEDE in a way that doesn't make a backup, therefore (close stream :abort t) cannot recover the data. SBCL works similarly.

Cost to Implementors:

None.

Cost to Users:

None. Programs who want a backup strategy need to use :IF-EXISTS :RENAME, not :SUPERSEDE anyway.

Cost of Non-Adoption:

Some implementations might implement a backup strategy for :SUPERSEDE, thus slowing down disk I/O in an unnecessary way.

Benefits:

Clarity. Avoiding unnecessary inefficiency.

Aesthetics:

Discussion:
  • Bruno Haible supports ALLOW.
  • Nikodemus Siivola supports ALLOW, and notes that :RENAME-AND-DELETE seems to provide for the :ABORT T recovery perfectly. :RENAME is of dubious utility, however, as there is not portable way to find out the new name.