Right, the renaming-a-symlink-to-a-directory hack is old unix lore, but it doesn't solve all problems in this space.
The specific problem that hack solves is that, on unix filesystems where the rename() system call can be implemented as an disk block write, one can be reasonably certain that the filename always points to *something*; that is, this eliminates the race condition in which the directory vanishes completely for a while, which network clients (among other programs) find disconcerting. But this does not solve all the problems of which readers get what view of the universe, whether any particular reader follows the new symlink to the new target directory, gets a mix of old directory and new directory, etc. That kind of thing is heavily dependent on implementation details (eg, does the process chdir() to the directory of interest or not?) that are way out of scope for an IETF document. As RobK says, there are just too many paths through the implementation maze for it to be safe to believe that anything based this closely on a filesystem is going to support atomic operations. This problem goes beyond rsync, HTTP or FTP have essentially the same problem, for the same reasons. Relying parties already have to cope with inconsistencies due to parts of the global database becoming unreachable (perhaps globally, perhaps just for some relying parties). Transient inconsistencies introduced during the publication process are just another form of inconsistency that relying parties have to cope with. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
