Re: [gfortran43] opening file twice...

*** Hendrickson wrote:

Dave Allured wrote:
*** Hendrickson wrote:
Dave Allured wrote:
fred wrote:
Hi,

I googled on this issue but I did not find anything relevant.

Say I have to open a file twice (or more):

open(unit=20, file='a.dat', form='unformatted', access='stream')
open(unit=21, file='a.dat', form='unformatted', access='stream')

Running my program, I get:

Fortran runtime error: File already opened in another unit

How could I fix it ?

Option to gfortan or special flag to open() ?

TIA.
It seems to me that this should be legal. My training was that
Unix-like file systems allow multiple read access on the same file. I
think this is a gfortran issue.
No, it is specifically forbidden by the standard. Mostly, because it's
impossible to specify what it could mean on a wide variety of systems.
What should happen if there are non-advancing reads on the two
"different" units? A rewind on one of them? Or a write or a close?
If 2 is OK, why not a hundred? It's a can of worms that can't
work portably.

Consider this definition for read access only, and for conventional
files on disk rather than more exotic devices. Each instance of an open
statement with a different unit number on the same file name defines a
unique and separate connection to the file. All connection information
such as access mode parameters, file position, and error status is
maintained separately for each connection. From the perspective of the
calling program, it as if there are multiple files that happen to
contain identical information. Any number of connections to the same
file are allowed.

This should easily handle all cases that you mentioned except for the
write. I think this is exactly how multiple connections were
traditionally handled by compilers such as XLF 8.1 and the SunWS
compiler. I am not an expert and can't immediately back this up with
references.

I see no significant problem for standardizing this behavior for read
access. If you still see a contradiction then please describe it.

There probably are no contradictions or unavoidable problems. The
file and access needs to be pretty severely restricted. It's not clear
what should happen when there is a close statement.

It seems fairly obvious that in what I described, a close statement
would simply close the logical connection between the file and the
specified unit number. What happens to files on other unit numbers is
irrelevant.

Many (most? all?)
current systems treat units 5 and 6 as synonyms for the * units. But,
there is no common agreement about what should happen to * when 5 or 6
is closed. It's worse when 5 or 6 are subsequently connected to a
different file.

Special unit number assignments are outside the scope of my proposal.

It's not that there can't be a definition, it's that
there are many good ones in use. That's mostly why Fortran invented the
INPUT_UNIT, etc., file names. It allows a programmer to avoid conflicts.


Remaining problems are the inquire command by file name, and write
access. I don't see either of these as difficult for ordinary files on
disk. Fodder for other conversations if anyone is interested. I expect
a standards group kicked all of this around a few years ago; I just
happen to not like the current result.

Almost all of the Fortran access methods contain a phrase like "whether
or not you can use this feature is system dependent." Personally, I
think a restriction to "read-only from disk files" is too restrictive to
be useful. I can also see your point of view.

Yes, after more contemplation I agree with that. With appropriate care
in the application, both read and write access through multiple unit
numbers can be reasonable and useful. I would change the device
constraint to include your "system dependent" wording and to also say
"the availability of multiple file connections is system dependent by
type of device".

--Dave
.

Quantcast