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 CLOSE when :abort is T and an old file is being superseded: OPEN implies that an implementation is allowed to have already deleted the old file, whereas 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:


This page is linked from: Proposed ANSI Revisions and Clarifications  

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively