Length of currently-open-for-write file is ambiguous or meaningless

[Robert Elton Maas <REM@IMSSS.SU.EDU>]

> Date: Tue, 19 Mar 1985  16:42 EST
> From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
> Subject: File-length on pathnames
>...
>  - This "operating system open" call may have some requirement for
>    exclusive access.  If some other process has the file open, then
>    the call to FILE-LENGTH may wait or fail.
>  - It is somehow more intuitive to have OPEN wait or fail than to
>    have FILE-LENGTH wait or fail.
>
>    I think that if there is any implicit guarantee in the CLM
> filesystem chapter that certain calls may not wait or fail whenever
> they feel like it, then it is bogus. ...

I agree completely with RAM, in fact I'd like to present a case that
FILE-LENGTH is meaningless when a file is open for write access by
self or by other task/user, and thus that it's quite reasonable for
FILE-LENGTH to fail (signal an error). FILE-LENGTH is supposed to tell
the length of the disk file, right? Well, if you're in the middle of
modifying it, either by replacing it with a new version you're in the
midst of creating, or by destructively modifying it and by changing
the directory attributes (length, disk record map, etc.), what exactly
do you mean by the length?
 (1) Length that it was before you started to modify it (that info
   probably already clobbered in case of destructive modification,
   although available if making new version which is not yet installed).
 (2) Length it will be when you close it (not known yet).
 (3) Some sort of momentary length as it currently exists (does that
   include I/O buffers which have been partially filled in RAM but not
   yet written to disk? buffers that have been written to disk but not
   yet included in directory? buffers that have been unwritten by
   decreasing the end-of-file pointer but haven't yet been expunged and
   thus still are part of the file in some sense that if the system
   crashed a wizard could recover them?)

Perhaps the function should include an extra argument that tells
whether you want the old info or a failure (error signal) or a
wait-for-close then new info or the instantaneous-guess info in such
an ambiguous case? Probably the default should be failure if you don't
supply the &OPTIONAL or &KEYWORD argument. If a file is open only for
read, I think there's no problem, the file can always be sized? (Or in
a network environment, perhaps there is only one copy of the file at
any time, and to size it you have to first move it to your site, which
means nobody else can have it open for read elsewhere? In such a
network it might fail even in case of open for read by somebody else
on another site, and the extra argument might be needed to say what to
do to resolve the problem.)

Since even in the case of a file you have open yourself the above
ambiguity can occur, with FILE-LENGTH of an I/O channel signalling an
error, I see no problem with implementing FILE-LENGTH applied to
filenames, where it's completely reasonable for the programmer to
have to be aware it might signal an error at random times when
somebody (yourself included) happens to have the file open for write.