Re: [RFC][PATCH] Rewriting revs in place in push target repository

From: Linus Torvalds <torvalds@osdl.org>
Date: Aug 13, 2005, 22:20 UTC
Message-ID: <Pine.LNX.4.58.0508131507260.3553@g5.osdl.org>
In-Reply-To: <20050813214725.GM5608@pasky.ji.cz>

On Sat, 13 Aug 2005, Petr Baudis wrote:

Show 6 quoted lines

> 
> * Does this break atomicity?
> 
> 	I think it does not in real setups, since thanks to O_RDWR the
> 	file should be overwritten only when the write() happens.
> 	Can a 41-byte write() be non-atomic in any real conditions?

That's not the problem.

The problem is that your change means that there is no locking, and you now can have two writers that both update the same file, and they _both_ think that they succeed. They'll both read the old contents, decide that it still is the one from before the push, and then they'll both do the write.

And yes, in most (all?) sane filesystems, the end result is that one of them "wins", and the end result is a nice 41-byte file. But the problem is that the other write just totally got lost, and the person doing the push _thought_ he had updated the thing, but never did.

To make things worse, with NFS and client-side caching, different clients that look at the tree at around that time can literally see _different_ heads winning the race. One of the writers wrote "first", and that client (and other NFS clients doing a read at that time) will see it succeed. But then the other pusher writes, and now people will see _that_ one succeed.

Confusion reigns.

In contrast, with the "create lock-file and rename" thing, if there is a race, somebody will win, and the loser will hopefully know they lost.

Show 6 quoted lines

> * Does this break with full disk/quota?
> 
> 	I'm not sure - we are substituting 41 bytes by another 41
> 	bytes; will the system ever be evil enough to truncate the
> 	file, then decide the user is over his quota and not write
> 	the new contents?

Probably not.

But how about you just try to copy the permission/group of the original file before you do the rename? I assume that if you're depending on permissions, it's either a shared group or by having the thing writable by others, so doing a

	if (!fstat(oldfd, &st)) {
		fchown(fd, (uid_t) -1, st.st_gid);
		fchmod(fd, st.st_mode & ALLPERMS);
	}
	.. do rename here ..

which should get you where you want, no?

		Linus