I believe that Matt's problem is different from bug ID 21837.
21837 was identified during investigation of a Legato Networker problem where
ctime was being updated inappropriately. The net effect of this was that files
that hadn't changed were being processed as if they had. I believe that Matt's
problem is the opposite; files that have changed are not being picked up by NDMP
incremental dumps. Matt's problem is currently being investigated.
FYI: the resolution for Bug ID 21837 required a change to Networker as well as
Data OnTap.
Greg Linn
Manager, NDMP Development
408.822.3752 telephone
-----Original Message-----
From: Chris Thompson [mailto:cet1@cus.cam.ac.uk]
Sent: Tuesday, June 06, 2000 1:33 PM
To: mphelps(a)cfa.harvard.edu
Cc: toasters(a)mathworks.com
Subject: Re: BudTool incremental backups behaving differently when using
NDMP
mphelps(a)cfa.harvard.edu (Matt Phelps) writes:
> OK, an update. I have removed the ufsdump/restore part from the
> equation. The same behavior exists when I move files to the NetApp
> with gtar using the "p" option as root to preserve file properties.
>
> NDMP incremental dumps are still not picking up the moved files.
> Again, an rsh'ed Ontap "dump" command DOES pick up the moved files.
Is this the same as, or related to,
| Bug ID 21837
| Product Data ONTAP
| Title setAccTime() sets the atime correctly, but also sets the ctime
| Problem Attempts to set only the access time of files end up changing the
inode
| change time as well. This is an issue for restore programs which are
| trying to restore the exact state of a file.
? What do the ctimes for for the files actually look like? (use "ls -lc")
21837 is supposedly fixed in 5.3.6 (maybe even 5.3.5R2P2?).
Chris Thompson University of Cambridge Computing Service,
Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG,
Phone: +44 1223 334715 United Kingdom.