Chris Sykes wrote:
> > I ran the system under strace, and saw (for example) the following, in
> > five straces of five different processes:
> >
> > 02:11:47.293131 rename("q1988na-000xqY", "proc.1988na-000xqY") = 0
> > 02:11:47.354497 rename("q1988na-000xqY", "proc.1988na-000xqY") = 0
> > 02:11:47.412207 rename("q1988na-000xqY", "proc.1988na-000xqY") = 0
> > 02:11:47.414376 rename("q1988na-000xqY", "proc.1988na-000xqY") = 0
> > 02:11:47.414559 rename("q1988na-000xqY", "proc.1988na-000xqY") = 0
>
> In rename(2):
> [1] "If newpath already exists it will be atomically replaced
> (subject to a few conditions - see ERRORS below), so that
> there is no point at which another process attempting to
> access newpath will find it missing."
>
> ...
>
> [2] "However, when overwriting there will probably be a window
> in which both oldpath and newpath refer to the file being
> renamed."
>
> Perhaps your program should link(2) the newpath to the oldpath, then
> on success unlink(2) the oldpath. link(2) will fail should newpath
> already exist. Of course this assumes that oldpath & newpath are on
> the same filesystem.
That would be most reliable, and you want to do that in case the
filesystem is NFS, too. (On the other hand, there are filesystems
that support rename(2) but not link(2)).
However rename(2) should not successfully rename from the _old_ path
more than once, whether the new names are all the same or not.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:18 EST