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@cfa.harvard.edu Cc: toasters@mathworks.com Subject: Re: BudTool incremental backups behaving differently when using NDMP
mphelps@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@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.