# Question about status = 'replace' with opening a file **URL:** \ **Category:** Uncategorized\ **Created:** [August 19, 2025, 6:44am UTC](https://fortran-lang.discourse.group/t/question-about-status-replace-with-opening-a-file/10343 "2025-08-19T06:44:28Z")\ **Posts on this page:** 5\ **Page:** 2
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [August 23, 2025, 2:58pm UTC](https://fortran-lang.discourse.group/t/question-about-status-replace-with-opening-a-file/10343/21 "2025-08-23T14:58:19Z")
> [@msz59](#): > > The POS specifier is allowed **only** for stream access. Yes, I was referring to unformatted stream. It occurred to me that the `POS` restriction for formatted stream might also be related to the `ENCODING` value in the `OPEN` statement. I have only experimented with this feature a little, but there are other discussions here about how it works, and the external file could be filled, for example, with variable-length characters. The only way to be sure that a `POS` value is not in the middle of a variable length character would be for that value to be returned by `INQUIRE` after it had been positioned correctly by a previous `READ` or `WRITE` statement. This is also consistent with the fact that `INQUIRE(...IOLENGTH=...)` only works for unformatted, not formatted, files, so there is no separate way (that I know of) to determine file storage units associated with an external file with variable length characters. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [August 24, 2025, 3:42am UTC](https://fortran-lang.discourse.group/t/question-about-status-replace-with-opening-a-file/10343/22 "2025-08-24T03:42:00Z")
> [@jwmwalrus](#): > > If REPLACE is specified and the file does exist, the file is deleted, a new file is created with the same name, and the status is changed to OLD. I was curious what exactly the consequences are for this, so I experimented a little with `status='replace'` in the `open` statement with this short program. ```auto program replace integer :: n=10 open(n,file='replace.dat',status='replace') write(n,'(i0)') n end program replace $ gfortran replace.f90 $ a.out && ls -i replace.dat 25089019 replace.dat $ a.out && ls -i replace.dat 25089019 replace.dat $ a.out && ls -i replace.dat 25089019 replace.dat $ flang replace.f90 $ a.out && ls -i replace.dat 25089019 replace.dat $ a.out && ls -i replace.dat 25089019 replace.dat $ a.out && ls -i replace.dat 25089019 replace.dat $ nagfor replace.f90 NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7203 [NAG Fortran Compiler normal termination] $ a.out && ls -i replace.dat 25088954 replace.dat $ a.out && ls -i replace.dat 25088956 replace.dat $ a.out && ls -i replace.dat 25088958 replace.dat ``` This is with MacOS. With both the gfortran and flang compilers, the same inode was displayed for the file after repeated runs. This was “as if” the old file were accessed and overwritten, which is what happens with `status='old'` in the open statement. With the nagfor compiler, each run created a new file with a new inode. I think the nagfor compiler behavior matches the fortran standard description, and the other two compilers are incorrect. I was wondering what consequences this might have. As far as fortran is concerned, I could not think of any, but there are consequences outside of fortran. Just one example, hard links (`ln` on unix/posix machines) allow several file names to be associated with a single file (i.e. several file names that all have the same inode). The nagfor code would behave differently than the gfortran and flang codes in these cases. I guess there might be other consequences too, such as how file backups of the file system behave, or maybe utilities like `make` would behave differently since the other file names would appear to have been modified [**edit**] with gfortran and flang, but not with nagfor. Is this serious enough to file bug reports with gfortran and flang? How do other OS and compiler combinations behave for `status='replace'` in the open statement? ---
**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\ **Post date:** [August 24, 2025, 6:22am UTC](https://fortran-lang.discourse.group/t/question-about-status-replace-with-opening-a-file/10343/23 "2025-08-24T06:22:48Z")
> [@RonShepard](#): > > I think the nagfor compiler behavior matches the fortran standard description, and the other two compilers are incorrect. It’s no surprise that NAG matches the standard word for word. But I wouldn’t say the behavior of the other two compilers is incorrect —it’s just an implementation detail. If I’m in a terminal, and want to empty a file, I issue `truncate -s 0` instead of `rm` followed by `touch`. Those compilers’ runtimes are just doing the equivalent syscall, since historically the cost of actual deletion followed by creation could have been huge —SSD and CoW filesystems are just a recent thing 😆 . > [@RonShepard](#): > > I was wondering what consequences this might have. Maybe there are consequences on Windows?.. but since on POSIX systems removing a file is actually an `unlink` call —i.e., a named file is actually a hard link to some underlying block(s), and by deleting you just remove the link, but the underlying data is still there, so other files that have hard links to said data are unaffected. > [@RonShepard](#): > > How do other OS and compiler combinations behave for `status='replace'` in the open statement? I just checked on Debian, with btrfs as the filesystem (which loves creating blocks whenever possible), and the behavior with `gfortran`, `ifx`, `flang-new` and `nvfortran` is similar to the one you showed. ---
**Author:** ![msz59](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@msz59](https://fortran-lang.discourse.group/u/msz59)\ **Post date:** [August 24, 2025, 1:22pm UTC](https://fortran-lang.discourse.group/t/question-about-status-replace-with-opening-a-file/10343/24 "2025-08-24T13:22:17Z")
> [@RonShepard](#): > > maybe utilities like `make` would behave differently since the other file names would appear to have been modified with nagfor, but not with gfortran and flang. I guess it is the opposite. As you report, gfortran and flang keep the inode number, thus they truncate the hardlinked file in-place, so all instances will show the new modification time. If nagfor really deletes the file (cutting the link) and recreates it with a new inode number, the other, remaining hardlinked instances will show the file unchanged. ---
**Author:** ![JohnCampbell](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@JohnCampbell](https://fortran-lang.discourse.group/u/JohnCampbell)\ **Post date:** [August 25, 2025, 9:08am UTC](https://fortran-lang.discourse.group/t/question-about-status-replace-with-opening-a-file/10343/25 "2025-08-25T09:08:56Z")
Some compilers differentiate between formatted or unformatted stream access files when implementing truncate. I think this relates to prervious non-standard support for stream like access files where truncate can be auto applied to formatted files, but not unformatted/binary files. [Previous page](https://fortran-lang.discourse.group/t/question-about-status-replace-with-opening-a-file/10343.md?page=1)