emulon Posted March 31, 2002 Report Share Posted March 31, 2002 I've just upgraded to 5.0, and have found that duplicating a volume with a large number of files corrupts several files, seemingly at random. This is running Retrospect 5.0 on a Mac G4 with OS X 10.1.3. The volume that I'm duplicating has a large number of files (about 250,000), and duplicating it with verify produces messages in the log like this: File “NSBitmapImageRep.html”: different data size (src: 37,924, dest: 0), path: “OSX/System/Library/Frameworks/AppKit.framework/Versions/C/Resources/English.lproj/Documentation/Reference/ObjC_classic/Classes/NSBitmapImageRep.html”. Sure enough, the file on the target volume is zero bytes in size. Re-running the duplicate yields similar messages but for different files. Another problem appears to be improper handling date/time stamps for files created or modified on days where daylight-savings-time to standard-time transitions occured. Again from the log: File “acoutput.test”: different creation date/time (src: 10/28/2001 6:00:28 AM, dest: 10/28/2001 5:00:28 AM), path: “OSX/Users/xxxxxx/automake/automake/tests/acoutput.test”. File “colon6.test”: different creation date/time (src: 10/28/2001 6:00:28 AM, dest: 10/28/2001 5:00:28 AM), path: “OSX/Users/xxxxxx/automake/automake/tests/colon6.test”. Link to comment Share on other sites More sharing options...
davidduff Posted March 31, 2002 Report Share Posted March 31, 2002 i have seen a similar problem with regard to dates. when i tried to duplicate a large volume which included my system file, i got several errors. on reading your post, i had an insight... i noticed first that the reported date discrepancies (both in your case and in mine) were off by exactly one hour. i assumed this was some kind of time zone conversion bug or something. then, i noticed that all the files in error were from days (such as 10/28/2001) in the fall when we switched from daylight savings time. so there must be a discrepancy between the two places in the code where date conversion is done. the place which decodes the dates on backup are using one algorithm and the place which decodes the dates on verify are using a slightly different algorithm and apparently there are time intervals where the two altorithms produce slightly different results, resulting in errors being reported in the logs saying that the modification times don't match. i'm not sure how serious these are - it probably won't hurt anything to ignore them, but it's definitely a bug dantz needs to patch! Link to comment Share on other sites More sharing options...
engrav Posted April 2, 2002 Report Share Posted April 2, 2002 same problem 30 files out of 80,000 have dates off by one hour strange problem, also rather cool tech support phone call yielded nothing and it is always Oct and April and off by one hour Save As fixes the problem but of course then there are new dates simply editing the date with File Buddy and ResEdit does not fix the problem so it is something in the file(s) Link to comment Share on other sites More sharing options...
dwalba Posted April 10, 2002 Report Share Posted April 10, 2002 Greetings: I'm having the problem with modify and creation date missmatches between source and destination files in a duplicate operation. My problem is very similar to that of two of the previous posters to this thread - I have about 18,000 files on an external FireWire drive, which I am duplicating to a directory on an internal HD on a TiBook. Retrospect 5.0 under OS X 10.1.3 reports 39 execution errors. From the retrospect operations log: File “93/8 Invoice”: different creation date/time (src: 4/3/1994 8:43:17 AM, dest: 4/3/1994 9:43:17 AM), path: “VST Documents/ NuFiles ƒ/ Standards/Displaytech/Consulting Invoices/93/8 Invoice”. all of the prolematic files were created or modified in April or October (mostly April). If the file was created in April, then the source is one hour behind the destination. If the file was created in October, then the source is one hour ahead of the destination. I'm working with Tech Support (single incident @ $69!). We'll see what happens. best...Dave Link to comment Share on other sites More sharing options...
IrenaS Posted April 10, 2002 Report Share Posted April 10, 2002 The date/time problem is actually a bug that we logged with Apple over a year ago under OS 9 that was fixed. Unfortunately, it's reasserted itself under OS X, though OS 9 still works. The problematic files will have creation dates on the days when the clocks change due to Daylight Savings Time. We are working with Apple to resolve this problem. Irena Solomon Dantz Tech Support Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.