Date: Fri, 28 Sep 2001 03:10:01 -0700 (PDT) From: "Crist J. Clark" <cristjc@earthlink.net> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/30887: dump allways saves files with modified c-time Message-ID: <200109281010.f8SAA1V57896@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/30887; it has been noted by GNATS. From: "Crist J. Clark" <cristjc@earthlink.net> To: Andreas Haakh <ah@Haakh.de> Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/30887: dump allways saves files with modified c-time Date: Fri, 28 Sep 2001 03:04:05 -0700 On Fri, Sep 28, 2001 at 10:13:56AM +0200, Andreas Haakh wrote: > >Description: > dump saves all files with changend m-time or changed c-time. > Large files, where only c-time is changed, e.g. mailfolders, databases > etc. will be saved day after day allthough the content of the > files did not change. > > >How-To-Repeat: > > >Fix: > ignore c-time anyway because there is no need to save files where only > the status has changed or This is not true. For example, when a file is mv(1)'ed, only the ctime will be changed, but I would expect most people would want it backed up. Even though the data in the file is "old," you want to have a fairly consistent snapshot of the filesystem (yes, dump(8) can only do that to a limited degree), and backing up the moved file is the only way to really do this. > add another flag to dump and ignore c-time, based on this flag. That's possible, but I'd have to think about what other changes you may be missing when you start to ignore ctime. Generally, a dump is something where you want to err on the side of caution. You would rather archive some things redundantly than risk missing something else. There are many examples where the very simple approach of dump(8) results in storing files over and over. Take the rotated *.<n>.gz logs in /var/log. Each time these get rotated, they are stored all over again. This ctime patch would actually stop that, but if you then were to restore your series of tapes, you would only ever get the last *.0.gz at the end. (Unless you tried to move stuff around between restoring tapes.) Actually, what I think best would in addition to the nodump filesystem flag, we could have a "noctime" flag. That is, individual files could be marked so they would be ignored if only their ctime changes. You could 'chflags noctime /var/mail' and fix your problem. But that fix takes some work. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109281010.f8SAA1V57896>