Jump to content

Different modify date/time

Recommended Posts

I have two Appleshare 6 servers running Retrospect 4.3 and OS 9. I have had no problems with the back ups prior to the daylight savings time a couple of months ago. Now I get on BOTH severs numerous execution error messages -Different modify date/time (set: 4/25/2002 12:06:23 AM. vol: 4/27/2002 7:06:59 PM) for file..... is one example.




The servers were fine before daylight savings. I am getting this on files that we have not touched for years...




Please help!

Link to comment
Share on other sites

  • 2 weeks later...

Tech Note NO. 304










During an operation Retrospect may indicate a mounted file server volume was not found, or Retrospect may want to back up files on a mounted file server even though the files have not changed since the previous backup. This problem is usually seen after a change of the system clock on either the Backup Macintosh or the mounted volume, which often occurs during a switch between standard time and daylight savings time.








Retrospect relies on a volume’s creation date and the volume’s name to identify it as a unique volume. If the system clock on either the network volume's computer or the Backup Macintosh is changed outside a certain range, AppleShare will compare the two system clock times and perform a time translation based on the differences. This AppleShare feature is enabled to facilitate sharing of data between workstations located in time zones different than that of the server. Unfortunately, this feature also interferes with Retrospect’s proper recognition of volumes and its incremental backups since all times on the server are different due to the time translation.




Note: AppleShare performs a time translation when the network volume's computer system clock time is 13 minutes greater or 17 minutes less than the local computer's time setting.








Synchronize both the Backup Macintosh’s clock and the network volume's computer clock with their respective appropriate control panels, to within the acceptable margin. Make sure that the Retrospect script in question uses the correct volume.





Link to comment
Share on other sites

Thanks for getting back to me. The problem still exits though.




I noticed that the time difference between the Retrospect Backup station and the network volumes were only off by 12 seconds. I synchronized the time anyway. This still did not fix the problem.




Also on one of these servers I am NOT even backing up anything remotely over the network-I am just backing up the hard drives connected to the computer via SCSI. I am still getting those error messages with the date and time.




Something is still wrong.





Link to comment
Share on other sites

A compare error appears if a backup set's copied file does not match the file from which it was copied. Retrospect will try to copy the file again during the next backup session or similar operation.




If you know the file was in use at the time the copying was done, a compare error is usually nothing to worry about. It simply means the file changed between backup and verification. The log entry example you provided listed different modifcation dates that had a discrepancy of 2 days which is well outside of the norm of anything I have seen. Was that an actual log entry or an example that you produced?




Are you continuing to have the same issues or have they gone away with a complete backup of the system? Do all the files in question have April or October dates (the provided example was dated in April). Also, are you doing a duplicate or a backup?







Link to comment
Share on other sites

  • 2 weeks later...

The files were not in use while they were being backed up. This was a actual log entry that was reproduced.




Here is another from last nights back up.


Different modify date/time (set: 6/15/2002 3:06:51 AM, vol: 6/17/2002 11:33:55 PM) for file "the path of the file)




I have checked the log and the set vol date/time changes with the current backup day.




This error happens for hundreds of files.




I am still continuing to have these back up errors and I am doing a backup.





Link to comment
Share on other sites

This can happen to some files that are created on the day we switch to Daylight Savings Time. Dantz has reported the problem to Apple and we are working with Apple torward a resolution. I have not seen a time difference of over two days, as you are seeing. But, in doing further research, it would appear that you are experiencing a known Apple issue.




You should consider using the client software, rather then mounting the volumes, to get around this issue.

Link to comment
Share on other sites

I'm having exactly the same problem with Retrospect 4.3 on an ASIP 6.3.3/Mac OS 9.0.4 server backing up its own hard drives to tape (a FireWire VXA-1 drive). It gives exactly 141 modify date/time errors every night. One thing I've noticed is that when I go into the folders to examine the files afflicted with this problem, the modified date on many of them changes to the instant I opened the folder (Today, current time). I'm guessing Retropsect is having the same problem. Whenever it verifies the files in the folder, they get the new modification time since Retropsect is looking at them again, thus generating the error.




I've run disk diagnostics on the drive thinking something may be wrong with the directories, but DiskWarrior gives it a clean bill of health. Any idea what is going on here? What would cause files in a folder to change their modified dates to the instant you open their parent folder?




Thanks for any advice!

Link to comment
Share on other sites

I have the same problem. One hour of difference between original and duplicated files (hundreds) from ASIP 6.3.3 MacOS 9.1 Retro 5.0 to firewire HD connected to PM G4 with MacOS X 10.1.5 and RetroClient 5.0.


The same problem I have also with copy (duplicated) some folders from win clients. Retrospect duplicate all folder every time - I lunch duplicate script retrospect copy every file, I lunch again - no file need to copy, restart PC client and lunch copy - copy all the files, next day - copy all the files again - I'm sure no file was used.


I haven't changed my scripts from two years and I hadn't have this problems with Retro 4.3.


All computers have the same time and timezone.

Link to comment
Share on other sites

Yes, I use always RetroClient for windows 5.6.112




This is my log (both computers have the same time and timezone):


+ Duplicate using W-Lorenzo at 10-07-2002 12:39


10-07-2002 12:39:14: Connected to MONIA ZACCHILLI (PIII 400)


- 10-07-2002 12:39:14: Copying Allplan on MONIA ZACCHILLI (PIII 400)


10-07-2002 12:50:19: Comparing Lorenzo_Backup on DOCUMENTI


File AT000018.001: different modification date/time (src: 3-11-1997 16:31:34, dest: 3-11-1997 17:31:34), path: Allplan\PRJ\n0000001.prj\AT000018.001.


File IMAGE_1.RLC: different modification date/time (src: 27-01-1998 14:55:08, dest: 27-01-1998 15:55:08), path: Allplan\PRJ\n0000001.prj\IMAGE_1.RLC.


File IM-2.RLC: different modification date/time (src: 2-03-1998 10:44:26, dest: 2-03-1998 11:44:26), path: Allplan\PRJ\n0000010.prj\IM-2.RLC.


.... (hundreds of files)


File IMAGE_31.RLC: different modification date/time (src: 6-11-1997 15:06:40, dest: 6-11-1997 16:06:40), path: Allplan\PRJ\n0000010.prj\IMAGE_31.RLC.


File tbwahl.dat: different modification date/time (src: 31-10-2001 17:08:44, dest: 31-10-2001 18:08:44), path: Allplan\PRJ\n0000010.prj\tbwahl.dat.


File ZE000000.000: different modification date/time (src: 31-10-2001 16:58:32, dest: 31-10-2001 17:58:32), path: Allplan\PRJ\n0000010.prj\ZE000000.000.


10-07-2002 12:51:32: Execution stopped by operator.


Remaining: 9773 files, 340.5 MB


Completed: 1255 files, 56.8 MB


Performance: 43.9 MB/minute (43.5 copy, 46.6 compare)


Duration: 00:12:18 (00:01:58 idle/loading/preparing)

Link to comment
Share on other sites

Are you duplicating PC files to a Macintosh? As a test, can you try duplicating the PC files to a different PC client computer? Does the modification time problem go away?




From your log, it appears that all the times are off by exactly one hour which may be related to a bug we've logged with Apple.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...