There are some issues that weren't brought up in the original thread.
Steve Losen scl@sasha.acc.virginia.edu wrote:
- Under normal circumstances, an incremental dump copies all files whose mtime or ctime has changed.
and others used similar phrases. But, of course, this isn't actually right: there's no record of whether the mtime has *changed*! What incremental dumps do is to include a file if either the mtime or ctime is greater than the recorded time of the reference dump.
Now ctime, being updated only by the server operating system, can be expected to only increase monotonically and never to be greater than the current time [assuming a well-behaved system clock, of course]. But mtime can be set arbitrarily by the file's owner, and there is no such guarantee for it. In fact, setting mtime far in the future guarantees that the file will be included in every incremental dump, and could constitute a sort of denial-of-service attack.
The tradition of checking mtime as well as ctime goes back a long way in the history of the BSD dump program from which, for example, Solaris ufsdump and NetApp dump are derived (at least conceptually). I've always thought of it as a fudge, designed to cover up for early operating system bugs which failed to update ctime when they should have done.
So, in respect of
- Netapp's NDMP dump has an option to ignore ctime. [...]
I would ask for an option to ignore mtime instead! (This was described in the context of NDMP, but the mtime+ctime rules described above are used by plain NetApp dump(1) as well.)
--
Steve Losen scl@sasha.acc.virginia.edu accurately described the original problem as follows:
This trips the atime on the file. The filer does this whether you like it or not. You can configure a filer to NEVER trip atimes with: vol options volname no_atime_update=on But if atimes matter to you, then why would you do this?
Some folks object to having the atimes of all files tripped by a virus scanner.
To solve 3, some virus scanners save the atime before reading a file and put it back when they are done.
Indeed they do, and there are also applications that dump using normal front-door access to the files that (at least optionally) try the same foul trick. It's enough to make any systems programmer turn in their grave, and ask: but, how can you do that? you can't tell whether someone else has updated the atime between your reading it and your trying to put it back!
The only "right" way to do this is not to update atime in the first place. Some operating systems provide a method, possibly privileged, of allowing files to be read without atime being updated. As Steve says, NetApp filers currently only have an all-or-nothing switch for this. But maybe a more selective option (no-atime-update-if-host=virus.scan -and-user=detox?) is what people who want to do transparent content scans should be asking for.
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.