"David Roundy" <[EMAIL PROTECTED]> writes: > Another alternative would be to simply always keep hash files that > refer to file or directory content in a fixed directory. The latter > option wouldn't be a bad idea at all, as it would also promote sharing > of disk space. In fact, that would be my leaning at the moment. If > we keep all HashedIO files in "pristine.hashed", then the whole > problem can't occur, and I don't see any downside. Well, I guess > there's the downside that cleaning the pristine.hashed directory could > be more complicated, as we wouldn't know how many other files might be > stashed away there. But we only cleanRepository in optimize, and > optimize doesn't need to be either amazingly fast or amazingly simple. I have been thinking about that approach before, but have discarded it on the paranoia argument. It still might be worthwhile: the downside is, that repair would pollute the pristine.hashed with a very large number of stale files: basically, any intermediate repository states that we write out, which aren't that few. So we really want to call clean_hashed every now and then while running repair (I think ext3 might have issues with very large directories, too, and also for space reasons...).
> One major advantage of this approach is that it decreases the number > of arguments to these functions, which should make them simpler and > safer to use. True, and it doesn't actually matter too much to have newpristine at all, and while we don't update the root pointer in hashed_inventory, we should be all safe. (We might need to extend clean_hashdir to take a list of root hashes instead of a single hash, thinking of that.) >> However, there is another issue with that approach. If we encounter hash >> failures in pristine, we might want repair to fix those -- which it will >> under >> forceHashSlurped as proposed, but won't under hashSlurped with a >> doesFileExist >> call in it. > > I don't think this is a problem. (Well, I have had experience of seeing some hash failures in http://darcs.net recently, although I haven't investigated too much, as I had some repository corruption issues before, so I have been so far assuming it's debris from that incident. It might still be worthwhile to have ability to repair such corruption if it happens. Probably rm-ing any such files at start of repair would be enough.) Yours, Petr. -- Peter Rockai | me()mornfall!net | prockai()redhat!com http://blog.mornfall.net | http://web.mornfall.net "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton on the subject of C program indentation _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
