OPEN error inconsistent
in [Fortran]
|
Prev: Random_number
Next: UF file reading by Fortran
From: Richard Maine on 13 Feb 2010 13:14 Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote: > In article <1jdudxw.15hopxm1j6ya9sN%nospam(a)see.signature>, > nospam(a)see.signature (Richard Maine) wrote: > > > > My understanding is that if you open a file with status='new' then it > > > will delete the old file if it exists, > > > > No. There seem to be multiple misunderstandings posted to his thread. > > > > From the standard: "If NEW is specified the file shall not exist." That > > is, it is a programming error to specify NEW if the file exists. The > > usual behavior is for that to be an error condition (except for the > > niggly detail about the standard not specifying error conditions). > > If I remember correctly, in f77 on VMS machines, an open with > status='new' would create a new file with a new version number even > if an old version existed. Yes. That's my recollection as well. I forget all the fine points, but systems with file version numbers do make things a bit different. That also gets into the above-mentioned "niggly detail" that the standard doesn't say it has to be treated as an error. I think I recall being initially surprised by the behavior on VMS, but concluding that it was at least sensible in the context of files with version numbers. Version numbers were also one of the reasons why trying to do a delete before the open was not robust. Even if the delete worked fine, that would normally just delete the highest version number of the file (or whatever version you had opened - normally the highest). SO you could delete the file sucessfully, but then find that there was still a file of the same name there. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 13 Feb 2010 15:01 Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote: (snip) > If I remember correctly, in f77 on VMS machines, an open with > status='new' would create a new file with a new version number even > if an old version existed. VMS (now OpenVMS) still exists, and some work is still being done on it. I believe that the VAX compilers only support up to F77, but that the Alpha and Itanium support later versions, up to F90 or F95. > That is, it would not delete the old > version and it would not generate an error condition. An open with > status='old' would open an existing file if it existed (or err if it > did not). An open with status='unknown' would open the old file if > it existed, or open the file with version number 1 if it did not > exist. An open with status='new' was the only way to create a new > file with a new version number when an old version already existed. > I did not use any of the later OpenVMS machines with an f90 > compiler, so I don't know if any of this changed by then. From your > sentence above, it looks like it did. (Or maybe my memory if off > about the details of status='new' in the first place.) I am not sure either. As far as I know, there isn't an F2003 or F2008 compiler. -- glen
From: Louis Krupp on 13 Feb 2010 16:26 Richard Maine wrote: > Louis Krupp <lkrupp_nospam(a)indra.com.invalid> wrote: > >> My understanding is that if you open a file with status='new' then it >> will delete the old file if it exists, > > No. There seem to be multiple misunderstandings posted to his thread. > > From the standard: "If NEW is specified the file shall not exist." That > is, it is a programming error to specify NEW if the file exists. The > usual behavior is for that to be an error condition (except for the > niggly detail about the standard not specifying error conditions). > > What you are describing is the behavior of status='replace', which is a > very different thing - also a very useful thing for exactly the reason > mentioned. The replace option was added in f90. Prior to that, it was > nontrivial to handle this kind of issue robustly. The closest one could > do was something like what the OPs code does, but that wasn't really > what I would call robust; there were multiple ways it could fail to work > as intended. > > In particular, doing a close with status='delete' requires that you > first be able to open the old file. There exist operating systems where > you have to know things about the file in order to be able to do that. > > For another example, it would be possible for another process to create > a file during the time between the deete and the open. That's a classic > "race condition." If you want to program robustly, you avoid counting on > things like that. > > For reasons like this, I was quite pleased to see status='replace' added > in f90. It allowed me to change some of my system dependent and > non-robust code into standard-conforming, robust code. > I stand corrected. It sounds like the OP's choices are: 1. Use f90. 2. Retry the deletion if it fails: 1 INQUIRE(FILE=FNAM,EXIST=FXIST) IF (FXIST) THEN WRITE(6,'('' DELETE EXISTING FILE'')') OPEN(IUNIT,FILE=FNAM,FORM='UNFORMATTED',STATUS='OLD', * ACCESS='SEQUENTIAL') 15 CONTINUE K = 0 * do something to delay one second * add and test a counter so we don't do this forever * maybe test the value of K (or is it system-dependent?) CLOSE(IUNIT,STATUS='DELETE',ERR=15,IOSTAT=K) GO TO 1 END IF I think the existing loop is a potential problem as it is without a delay; I try to avoid doing that. Louis
From: Louis Krupp on 13 Feb 2010 16:49 Louis Krupp wrote: > Richard Maine wrote: >> Louis Krupp <lkrupp_nospam(a)indra.com.invalid> wrote: >> >>> My understanding is that if you open a file with status='new' then it >>> will delete the old file if it exists, >> >> No. There seem to be multiple misunderstandings posted to his thread. >> >> From the standard: "If NEW is specified the file shall not exist." That >> is, it is a programming error to specify NEW if the file exists. The >> usual behavior is for that to be an error condition (except for the >> niggly detail about the standard not specifying error conditions). >> >> What you are describing is the behavior of status='replace', which is a >> very different thing - also a very useful thing for exactly the reason >> mentioned. The replace option was added in f90. Prior to that, it was >> nontrivial to handle this kind of issue robustly. The closest one could >> do was something like what the OPs code does, but that wasn't really >> what I would call robust; there were multiple ways it could fail to work >> as intended. >> >> In particular, doing a close with status='delete' requires that you >> first be able to open the old file. There exist operating systems where >> you have to know things about the file in order to be able to do that. >> >> For another example, it would be possible for another process to create >> a file during the time between the deete and the open. That's a classic >> "race condition." If you want to program robustly, you avoid counting on >> things like that. >> >> For reasons like this, I was quite pleased to see status='replace' added >> in f90. It allowed me to change some of my system dependent and >> non-robust code into standard-conforming, robust code. >> > > I stand corrected. > > It sounds like the OP's choices are: > > 1. Use f90. > > 2. Retry the deletion if it fails: > > 1 INQUIRE(FILE=FNAM,EXIST=FXIST) > IF (FXIST) THEN > WRITE(6,'('' DELETE EXISTING FILE'')') > OPEN(IUNIT,FILE=FNAM,FORM='UNFORMATTED',STATUS='OLD', > * ACCESS='SEQUENTIAL') > 15 CONTINUE > K = 0 > * do something to delay one second > * add and test a counter so we don't do this forever > * maybe test the value of K (or is it system-dependent?) > CLOSE(IUNIT,STATUS='DELETE',ERR=15,IOSTAT=K) > GO TO 1 > END IF > > I think the existing loop is a potential problem as it is without a > delay; I try to avoid doing that. Oops. Make that: K = 0 15 CONTINUE Louis
From: dpb on 13 Feb 2010 16:52
dpb wrote: .... > ... it's not this app that is the other process I think is clear. That > it's something like the anti-virus or somesuch is likely why it appears > intermittent as it does. > .... Oh, these files aren't on a network share or somesuch mayhaps??? -- |