Re: close(status=delete) on a missing file

From: James Giles (jamesgiles_at_worldnet.att.net)
Date: 08/17/04


Date: Tue, 17 Aug 2004 00:29:38 GMT

Dr Chaos wrote:
> James Giles <jamesgiles@worldnet.att.net> wrote:
...
>> The point I was making is that any attempt to delete a file that
>> *does* have the appropriate privilege should not appear to
>> work and yet leave the file in existence. The file *should* be
>> gone afterwards.
>
> On Unix, from the point of view of the Fortran I/O and computational
> model, OPEN(unit=?), CLOSE(unit=?), etc won't it be true
> that the file is no longer in existence?

No. The same Fortran program will often still be able to open
and use the same file through the same or different filename,
depending on what the the reason was that the file failed to
delete.
>
> From Fortran's point of view, anything IT put in there is now gone.

Not necessarily. If the information is still available, it's still
available
to something written in Fortran. Or, are you claiming that Fortran is
not capable of doing I/O on all the files present in a UNIX environment?

...
>> If not, there should be some indication of why.
>> There should also be a more aggressive form of delete that can't
>> be blocked no matter who else is using the file.
>
> OK. What would happen to the other processes, would they then
> get some kind of I/O error (just as if you popped out a floppy
> disc)?

That's a good analogy. If the owner of the data requires that it be
deleted with extreme prejudice, the lesser of two evils is to have
subsequent I/O from those other processes fail than to let them
continue to use data that *should* be gone!

-- 
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare


Relevant Pages

  • Re: C++ Bounds Checking
    ... how could any simple test be significant compared to an I/O ... me to buy _UNIX Unleashed_. ... the least informative, superficial, and poorly written books I've ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Re: read(5,*) problem?
    ... >> I can see no reason that your faith in Fortran should be shaken thereby. ... (I presume that you also don't want it interpreted as a divide in I/O ... The spaces are also lot allowed in undelimited strings. ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Re: Most elegant way to read to allocatable array?
    ... That would be a lock that's needed whether the I/O used unit numbers ... locked longer during OPEN and CLOSE since you're modifying ... Fortran is even more underspecified. ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Re: Binary or Ascii Text?
    ... You mean, before Unix developed a uniform notation for text streams, ... misunderstanding Pascal i/o for generations now. ... and structured files -- if not always the same terminators. ...
    (comp.lang.c)
  • Re: How to create a new folder in FORTRAN 77?
    ... use either Unix or Windows nowadays, ... Folder is extremely commonly used terminology. ... And lots of those people use Fortran. ...
    (comp.lang.fortran)