Hi,

On 2022-04-27 09:07:37 +0200, Thomas Schmitt wrote:
> i wrote:
> > > So if it got created by the script, maybe it was deleted or renamed
> > > shortly afterwards and created again 30 seconds later ?
> 
> Vincent Lefevre wrote:
> > The script doesn't do that. The file is created with
> >   echo "* $fqdn ($(${1:-.}/config.guess) / ${line#PROC:})" > "$out"
> > [...]
> > Note that if the file were created again, the first line with the FQDN
> > would no longer be in the file, but the line is still there.
> 
> This is indeed a riddle. But is there a hard reason not to insert
> 
>   stat "$out" >/tmp/stat_out_after_creation 2>&1
> 
> after that line and to compare /tmp/stat_out_after_creation with the
> stat(1) result when the expected file appears 30 seconds later ?

Because the issue was unexpected (this was the first time it occurred
after 11 years of testing: I wrote the first version of the script in
2011, and I typically look at the output file just after starting the
script) and is probably unlikely to occur again.

Moreover I don't see why this behavior would be allowed with a local
filesystem. If one has in a script with "set -e" (to detect errors,
like in my script)

  something > out
  something else

and if in an interactive shell, one can see the side effect of
"something else", then one should expect file "out" to be visible
in the directory. (This is/was not necessarily the case with NFS
due to caching, even on the same machine.)

> > https://gitlab.inria.fr/mpfr/misc/-/blob/fed7770cf5f712871bd116ef80d93ea5885fc3f7/vl-tests/mpfrtests.sh
> > # Written in 2011-2021 by Vincent Lefevre <vinc...@vinc17.net>.
> 
> So you are supposed to really know what it does. :))

Yes, I'm the only author of the script, and I've been working on
it for 11 years. It was much simpler 11 years ago, but there was
already the same kind of code concerning the output file.

> Whatever, it is fewly plausible that the file would not show up in stat(1)
> or ls(1) but the script can happily do
>   ... >> "$out"
> Each of these lines is supposed to do a name lookup of the file.

unless there is some caching bug. The script is likely to run on
the same CPU core, so that the file would still be visible along
the script, possibly via a cache. But some process running on a
different core might not see it for some time.

However, there's also the fact that the birth time was 30 seconds
ahead of the actual file creation, while there was no lockup.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Reply via email to