I wrote: [...]
As I understand it, this copes with cases like the following:
Suppose one has a quota tree /home, divided into two for dumping purpose, with directories such as
/home/part1/alpha /home/part1/bravo /home/part1/charlie /home/part2/delta /home/part2/echo /home/part2/foxtrotSometimes users are moved from one part to another to rebalance the size of the dumps. Now suppose:
- Level N dumps of /home/part1 and /home/part2 have been taken.
- /home/part1/juliet is rename(2)'d as /home/part2/juliet.
- Level N+1 dumps are now taken.
Pre-6.0, the level N+1 dump of /home/part2 would know to dump /home/part2/juliet itself, because its mtime & ctime have changed, but would not know to dump its contents. Hence a subsequent restore using this dump would cause all juliet's files to disappear - except the ones she had modified between (1) & (3).
[...]
The above scenario is actually not unlike what we do with our /home quota tree, and cases like juliet's have been a lurking worry at the back of my mind! Now to test whether the 6.0 solution using the oldmaps actually works... who shall I pick on as the victim to lose all their files if it doesn't? :-)
Well, I picked a couple of testing accounts, switched them between file sets that had a level 0 dump yesterday and a level 9 dump today, and looked at the result. Only the directories actually moved were included in the level 9 dumps, not their contents.
So either I didn't understand after all, or this splendid new facility has bugs in it ... :-(
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.