selfupdate fails with '"/tarballs/ports.tar" (in release) failed: No such file or directory'

[Richard L. Hamilton]

> On Nov 14, 2016, at 18:48, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> No. There is a bug in mprsyncup in which updates of our private master rsync server are not atomic. I think that occasionally the public master rsync server must be connecting to the private server at exactly the wrong moment and ends up copying a broken configuration.
> 
> I'm currently rewriting mprsyncup to hopefully lessen the likelihood of this problem. Eliminating it completely is quite difficult because there isn't an easy way to atomically replace more than a single file on a server, and even if that were possible, rsync doesn't ensure that a consistent set of files is transferred.
> 


I think the following would provide the appearance of an atomically updated directory, more or less:

If one had the directory "version_0001" and the symlink  "directory" -> "version_0001",  and then created the directory "version_0002" and the symlink "directory_new" -> "version_0002" one should be able to atomically rename "directory_new" to "directory" (replacing the old symlink with the new one).

Some say that it's not assured that "mv" would do a rename; the code gets a little tricky to deal with case-insensitive directories, and I'm not going to spend the time to figure that out; one could always do a "real" rename in perl or something.

A process handing out the contents would still have to chdir() via the symlink and hand out paths relative to the current directory, to work with a consistent set of files.  That might take an interposing script or the like to pull that off.   One would not want to blow away the old directory tree for at least twice a generous time-to-copy.