Stefan Sperling wrote: > On Mon, Mar 01, 2010 at 06:14:33PM +0000, Julian Foad wrote: > > On Thu, 2010-02-18, Neels J Hofmeyr wrote: > > > The one thing left now is: > > > > Can someone explain a motivation for even creating a database row before > > > > the pristine file is moved into place in the pristine store? I currently > > > > don't see why it can't be way simpler. > > [...] > > > "Simultaneous or multi-threaded clients" would be my first reaction to > > that particular question. > > If two threads write to the same pristine, the content written > will be the same (except in case of a SHA1 checksum collision > which we choose to ignore). So, thread 1 writes to a tempfile, and > when it's done, it moves the tempfile into place. The new filename > of the tempfile being based on the SHA1 sum of the written content. > If thread 2 does the same concurrently, the end result will be the > same -- the file will only exist once at its SHA1 sum name.
Yup, the file will be OK. I didn't have any specific failure mode in mind, and I can't think of one now. If there is some reason, then we can tackle it when we find the reason. +1 on KISS. > Of course, writing the same pristine more than once is redundant. > So we could try to optmize this redundancy away. But I don't think > it is worth it. [...] Agreed. - Julian
