Feature proposal and implementation plan: --delete-delay
Edwin Olson
eolson at MIT.EDU
Wed Apr 14 23:21:17 GMT 2004
Hi folks,
One feature I've wanted in rsync is the ability to delete files that no
longer exist in the source *after some specified grace period.*
The functionality I'm looking for is a backup system that won't actually
delete files until a week or two after the user does. This would:
1. Protect against accidental file deletions; the user would have
some time to realize the mistake and retrieve a backup
2. Keep the backup machine tidier, and reflect more closely the
source directory's structure.
It seems to me the difficulty is in noticing when the file was "first"
deleted and then keeping track of how much time has elapsed.
Here is a proposed method of doing this:
1. When a file is first discovered to be obsolete due to the source
file having been deleted, rename the local file
"originalfilename__RSYNC_YYYYMMDD".
2. Whenever we are asked to delete a file (in delete_one), check the
filename. If it is in the form above, check to see if the required
amount of time has elapsed (via a --delete-delay=NDAYS argument). Delete
as appropriate. If the file isn't in the correct form, the file only
became obsolete just now; rename the file with the current date.
3. These modified filenames would be exposed to the user. (Yes, a
big ugly.)
An alternative strategy which would preserve the filenames would be to
have an auxillary database file that stored the timestamps. However, I
can imagine a thousand things that could go wrong here.
I also considered encoding the timeout information in the
modified-time/access-time fields, but that seems very hackish and,
again, I can imagine a thousand things that could go horribly wrong.
What do you think? I'm willing to do the work, but I'd like to implement
the feature in the best possible way (any improvements?) and I was
wondering (provided the implementation is adequately robust/clean) if
you would be willing to add such a patch to CVS. (Or is it
"philosophically" the incorrect behavior and thus undesireable
regardless of its implementation?)
Thanks,
Ed
More information about the rsync
mailing list