Re: "dpkg --info" produces errors if /tmp NFS mounted
I got a number of responses to this question, so I will summarize them here.
(I hope this is OK with everyone that has participated.) I also have how other
OS cope.
Trond Myklebust wrote:
>In NFS you cannot delete a file that another process is holding open
>as this would cause the file to physically disappear. The standard
>trick (on all UNIX NFS clients) is to rename the open file to some
>unique and very unlikely name (typically .nfsxxxxx), and then to
>postpone deleting it until it is closed. Since deleting such a file
>makes no sense, it is not allowed.
This is true, but other Unix OS are slightly different. See below.
cks@utcc.utoronto.ca said:
> The kernel must rename the file in the same directory, because this
> directory is the only one that is guaranteed to be writeable enough to
> rename the file into (if it was not writeable, the unlink operation
> would also fail[*], so we can fail the unlink() syscall).
> [...]
> [*: Well, assuming normal Unix semantics. The NFS server may implement
> rather different ones if it wants to, but at that point lots of
> things get hosed.]
In that case, would it be possible to try another directory first (eg the
mount-point, which cannot be deleted anyway), and only revert to the same
directory if the first attempt fails? Then again, it probably would be easier
(and more portable) just to fix dpkg. From memory, Unix operating
systems are the only ones that support weird operations like deleting
an open file anyway.
russell@coker.com.au said:
> NFS doesn't work on handles of open files (as UNIX, DOS, OS/2, and NT
> semantics do and the SMB protocol does). It works on reading and
> writing blocks from files in a stateless fashion. So the only way the
> server can know that the client has closed a file is if it does
> nothing on the file for an improbably long period of time. This is
> why if you write to an ELF binary from an NFS client then you can't
> run it on the server for 24 hours (try it). [...] I
> think that applications should not be written to require deleting open
> files without good reasons. I can't think of a really good reason for
> doing this in dpkg.
So maybe I should file a wishlist bug against dpkg... ie it should wait for
the background process to exit (probably tar, but I haven't checked) before it
deletes its temp files that are still being written to at the same
time...
Just out of interest, I wanted to see what happens with other OS:
- Ultrix and OSF/1: The .nfs* file *can* be deleted. Any further writes to
this file result in "stale filehandle" error.
- SunOS 5.7: rm .nfs* returns no errors, but the file is not deleted, hence
the directory cannot be deleted.
- Linux: rm .nfs* returns with an error.
Brian May <bmay@csse.monash.edu.au>
Reply to: