alex@am.sublink.org (Alex Martelli) (06/05/91)
bp@chorus.fr (Bruno Pillard) writes:
...
:What about:
: ( /bin/rm $FILE ; sed s/"$ENTRY"/"$NEWENTRY"/ > $FILE ) < $FILE
:I understand that this may look harmful at first glance because of the
:/bin/rm of your precious file but it works perfectly for me under sh
:and (t)csh.
:
:Is there any problem using that construction ?
Normal Unix semantics, when a file is opened for reading (from the
outer shell, via the '<' redirection) and then unlinked (by the rm),
is that the file's directory entry is removed, but its contents are
still available to the process reading it; when it's finally closed,
assuming the link removed was the last one, its space will be reused.
If, however, $FILE stands in for a file remotely mounted in such a
way that usual semantics are not necessarily preserved (I'm thinking
of NFS), then I'm afraid you might lose it, if it's large enough not
to have been entirely read at the moment it's rm'ed. I can't test
here at home, and I hope somebody will show why this is wrong, but...
--
Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 2:332/407.314 (home only).jik@cats.ucsc.edu (Jonathan I. Kamens) (06/06/91)
In article <1991Jun04.224044.1971@am.sublink.org>, alex@am.sublink.org (Alex Martelli) writes: |> If, however, $FILE stands in for a file remotely mounted in such a |> way that usual semantics are not necessarily preserved (I'm thinking |> of NFS), then I'm afraid you might lose it, if it's large enough not |> to have been entirely read at the moment it's rm'ed. I can't test |> here at home, and I hope somebody will show why this is wrong, but... Although the NFS protocol doesn't know anything about files that are open on an NFS client and then unlinked, many (most?) NFS client kernel implementations deal with this properly. If you open a file on an NFS filesystem and then unlink the file on the same machine, then client kernel realizes what you're doing and doesn't really send then unlink NFS protocol request to the NFS server. Instead, it sends a rename address to change the name of the file to something like .nfsXXXX (where XXXX is replaced by a number) in the same directory, and then actually unlinks the file after the processes that have opened it on the client have closed it. -- Jonathan Kamens jik@CATS.UCSC.EDU
brent@terra.Eng.Sun.COM (Brent Callaghan) (06/06/91)
In article <1991Jun04.224044.1971@am.sublink.org>, alex@am.sublink.org (Alex Martelli) writes: > Normal Unix semantics, when a file is opened for reading (from the > outer shell, via the '<' redirection) and then unlinked (by the rm), > is that the file's directory entry is removed, but its contents are > still available to the process reading it; when it's finally closed, > assuming the link removed was the last one, its space will be reused. > > If, however, $FILE stands in for a file remotely mounted in such a > way that usual semantics are not necessarily preserved (I'm thinking > of NFS), then I'm afraid you might lose it, if it's large enough not > to have been entirely read at the moment it's rm'ed. I can't test > here at home, and I hope somebody will show why this is wrong, but... NFS implementations preserve "last open" semantics for a single client by renaming the file to an "obscure" name. The file will apparently be deleted from the directory, but its filehandle will still be valid. The shell script will run correctly on NFS filesystems. On the other hand; if you're using the file on on one client and it gets removed by another client then you're SOL... Aside: Unix shares "last open" file behavior with other OS's of its era. Is there a compelling reason for this behavior ? The most common argument is that it allows a process to set up a temporary file that will disappear itself if the process dies, though "last open" appears to be a clumsy way to achieve this. -- Made in New Zealand --> Brent Callaghan @ Sun Microsystems Email: brent@Eng.Sun.COM phone: (415) 336 1051