Retrospect 5.1.175 wants to do full backup, not incremental on previous firewire

[rtcstudio 0]

I'm on a Mac G4/733, 1.5 Gig RAM, with OS 10.3.2

Retrospect Backup ver. 5.1.175

 

During a project (Pro Audio) I'll use Ret to backup to an internal or a firewire ext. drive, making incremental backups every day. Once the project is finished I make a Sony AIT tape backup.

 

Sometimes, I'll come back to a completed project to make slight changes (like doing a radio remix) and will want to add that to the firewire Retrospect backup. Sources are the same (usually two drives both selected) and the destination is the Retrospect backup file. At this point Retrospect wants to start from scratch and RE-backup the entire project, not just incrementally backup what I've changed (like over 100 gig).

 

Here's what I've tried:

 

As per the online suggestions, I changed my clock back to what it was before Daylight Savings time kicked in. No difference.

 

I tell Retrospect to "Forget" the destination file listed in it's list. I select "More" and re-navigate to the backup file on the firewire drive. No difference.

 

I have not tried to rebuild or start from scratch. I'm trying to find out why this happens and if there's a fix.

 

The only thing I can think of right now is that perhaps Retrospect does not like for destination drives to change, like going from an internal drive to an external firewire drive (remounting the physical drive in a removable tray for storage).

 

Is that true, is Retrospect sensitive to physical destination changes? Do I need a new version?

 

Thanks for the help

[rtcstudio 0]

Just to clarify something that another Use Group member (not this user group, one that actually responds to new posts...) asked in trying to help me with this situation:

 

 

 

The source drives have ALWAYS been two firewire drives, or specifically, two Granite Digital firewire drives in removable trays. They have never been erased and restored, they are exactly the same as they have been from the beginning of the project discussed. So inception dates etc. have not been changed, so some files date back to last October.

 

 

 

I am using Retrospect's backup type "FILE" to store the backup AND catalog file together in one MAC file on a third hard drive. This drive used to be my secondary drive INSIDE my Mac. It now is in a third firewire drive in a removable tray.

 

 

 

This project has ALWAYS been under Mac OS 10.3.2.

 

This project has ALWAYS been under Retrospect version 5.1.175.

 

 

 

No OS changes, no Retrospect version changes, no computer changes WITH THE EXCEPTION of moving the backup drive from internal to external firewire. IS THAT THE PROBLEM??

 

 

 

Retrospect is not seeing that the backup file is valid, but it gives NO ERROR message. After I navigate to the backup file using "MORE" in the destination dialog box, and select the backup file, it appears in the immediate backup dialog box. Retrospect scans the two drives, and then wants to do a COMPLETE backup of all 111.8 GIG INSTEAD of simply incrementally backing up my new files, which are around 500 meg.

 

 

 

Hopefully someone here will respond today. I was told by Customer support that two technicians read this board. There have been no new posts since I posted mine in this category, it couldn't take that much time to read these two entries.

[rtcstudio 0]

Today I tried putting the hard drive with the original Retrospect backup file on it BACK inside my MAC, thinking that THAT could be causing Retrospect to be confused.

 

No avail, Retrospect still wants to RE-backup all 111 GIG of the project, NOT just the new files. I tried different clock settings, rebooting, re-pointing Retrospect to the files etc. Nothing would make it change its mind.

 

So, I'm going to try "repair" and if that doesn't work I'll just re-backup.

 

I'd just like to say that this is the WORST tech support I've ever seen in a professional product. I've never needed you guys before, but could not get the simplest question answered unless I paid an additional $70. It seems to me that since I have NEVER availed myself of any FREE 30 day tech support, I could be entitled to one simple question that a tech here could probably answer in 10 minutes. I've bought every upgrade and version for at least the last 5 years. I think I'm due.

 

Another thing to point out is that 30 days is NOT enough time for this sort of problem to manifest itself.

 

The two technicians that I was told would be monitoring this forum must both be on Spring Break. That's great. You know, somebody ought to be monitoring this thing AT LEAST every couple of days.

 

There has been NO traffic on this forum since I posted my original problem. I can't see that your whole tech support department is THAT busy that you must demand one of the highest premiums in phone help around. Perhaps you purposely avoid the forums to force people to pay up on the phone tech support.

 

Not that you care, but I will never recommend this product again without making sure that the customer I recommend it to is well aware of the state of your support section. As I've stated before, I have been responsible for scores of people buying and using Retrospect, including a couple of large multimillion dollar companies. Since I do consulting on Pro Audio computer systems, Retrospect has always been my program of choice for these types of installations, as well as in my own studios. I have been loyal to the point of argument with advocates of your competitors.

 

Obviously that counts for nothing here. Perhaps I should check out MEZZO.

[natew 0]

Hi

 

We do our best to post frequently here but sometimes post volume, call volume, short staffing due to any number reasons make that difficult. Our number one goal is to support our users and we do our best to do it for free on our user forum. As for me I will do my best to help resolve this problem.

 

Can you please post the results of the following test?

-Run a duplicate copying all of the data.

-immediately after that run another duplicate making sure not to open your editing software.

 

How many files are copied in this scenario?

 

Next:

-Open your editing software and make some minor edits to a project and then save it.

-run the duplicate again

How many files are copied at this point?

 

Does this happen with files other than those used with your audio editing software?

 

Thanks

Nate

[rtcstudio 0]

Quote:

---

Hi

 

We do our best to post frequently here but sometimes post volume, call volume, short staffing due to any number reasons make that difficult. Our number one goal is to support our users and we do our best to do it for free on our user forum. As for me I will do my best to help resolve this problem.

 

---

 

*** Thanks for the reply, but 8 days later I've had to move on. How can you expect me to continue working when my BACKUP is not working? I went ahead and RE-backed up the project (which took almost 20 hours, it's 111 GIG) and have erased the offending Retrospect Mac File. * * *

 

Quote:

---

 

Can you please post the results of the following test?

-Run a duplicate copying all of the data.

-immediately after that run another duplicate making sure not to open your editing software.

 

How many files are copied in this scenario?

 

Next:

-Open your editing software and make some minor edits to a project and then save it.

-run the duplicate again

How many files are copied at this point?

 

Does this happen with files other than those used with your audio editing software?

 

Thanks

Nate

 

---

 

What you have asked would take me literally 2-3 days of running your tests at least, unless DUPLICATE is a lot faster than Immediate Backup. This project is 111 GIG BIG. It seems like you could come up with a suggestion of what's going on based on my detailed posts ("it might be this, it might be that..."). And add to that the possibility of you guys taking another 8 days to get back to me? What you have asked is something you might ask a Beta Tester to do, but I just don't have the time for these sorts of experiments (I beta test for other companies and know the time involved in running this type of problem down, my hope is that you had seen similar problems before and would have some suggestions on how to prevent it). I have too much work to do already to shut my studio down for 2-3 days.

 

This forum is simply the lowest thing on the tech support Totem pole. Mayoff has just made it clear in another post that none of you is obliged to help us at all. There are STILL posts on this forum within the time frame of my first post that have no replies, even posts older than mine. I know you guys are busy, but this is not an alternative for me.

 

Along those lines, you need to make your phone staff and customer service staff aware that they should NOT say that techs regularly answer posts in this forum and that it is a viable free alternative to pay tech support. Because that is what they are saying and implying when we call in for help. People needing help with critical backup problems can't wait 3 days, let alone 8 days (there are people on this forum who have waited FOURTEEN DAYS with no response still.) The people on your phones need to be up front with us and just say it can take over a week for a response on the forums. After hearing that, more of us would probably cave and just pay the dough.

 

And again, until you update it with meaninful information for advanced users, it does no good to point people to your Knowledge Base and Tutorials. Those are for beginners only and have nothing but the most elementary suggestions, pretty much akin to "have you checked your cables?" type information. Most of that ground is covered in the manual.

 

You know, it's just frustrating to have been your customer for over 5 years, and this is the first time I've needed your help, and your response is to charge me MORE money for that help. Dantz has the right to do business the way they want, and it's a sure bet that with "millions of users" you aren't going to be too concerned about the few individuals on this forum complaining about the lack of good response here. That's the way of things now in Corporate America, so it's not fair for me to expect anything different from Dantz.

 

On a positive note, I suppose I should point out that in over 5 years, this is the first major problem I've had with Retrospect that I could not solve myself. It will remain a mystery that I hope never reappears.

 

If you or anyone has any concrete ideas of what MIGHT have happened that I have not already gone over in my posts, I hope you post them.

 

Thanks

[natew 0]

Hi

 

I certainly understand your frustration. I can assure you it frustrates us when we can't help customers on the forum. Like I said I will do what I can to try to help you resolve this.

 

Did this problem coincide with the start of daylight savings time? If so then you really have no choice but to backup everything again. Macs (HFS+ filesystems to be exact) keep time based on local time. When the time changes it changes modify and create dates on all files by one hour. Retrospect correctly detects the time changes and backs up everything again.

 

Retrospect's matching criteria are pretty bulletproof so it won't randomly backup everything without some other cause. The test I asked you to perform was to verify that the matching was indeed functioning and to see if your editing software was changing files somehow so they get backed up.

 

Rather than backup the entire drive try it with a single subvolume or a test set of Data. If we can establish that Matching is working then we can look for other causes.

 

Thanks

Nate

[rtcstudio 0]

Quote:

---

Hi

 

 

 

Did this problem coincide with the start of daylight savings time? If so then you really have no choice but to backup everything again. Macs (HFS+ filesystems to be exact) keep time based on local time. When the time changes it changes modify and create dates on all files by one hour. Retrospect correctly detects the time changes and backs up everything again.

 

---

 

 

 

* * * *

 

If this is the case, then I can pretty much guarantee that this is what happened, because I came back to this project after the time change. You need to UPDATE your Knowledge Base as it does NOT mention Daylight Savings Time, it ONLY mentions changing TIME ZONES. Your knowledge base says that you can set the computer's clock back to the original time zone and that all will be well (this did not help me, I tried it). But if, as you say, the MAC actually changes ALL the creation times on all connected drives then this is a built in problem that will ALWAYS occur.

 

 

 

I would strongly suggest making the DST issue clear in the manual as well. It is not there either, and it seems staggering to me that it would be ommitted.

 

 

 

I have two questions regarding this:

 

 

 

1.) Since my project drives and the backup file drive were NOT connected to the computer until after DST, are you saying that when I connected them and booted up the first time since visiting this project last November that the computer (now on DST) scanned all the files on the just connected drives and RE-WROTE all the time stamps on every file on the drives before they ever showed up on the desktop? This seems like a dangerous intrusion of the OS.

 

 

 

2.) If this is the case, and you guys KNOW this is how Macs do it, then why in Heaven's name do you not have a Retrospect Preference to obey Daylight Savings Time? The Mac KNOWS it's on DST. Why can't Retrospect scan the computer's clock and determine that it IS on DST? This can't be a difficult preference to add: either OBSERVE or IGNORE DST.

 

 

 

* * * * * * *

 

Quote:

---

 

 

 

 

Retrospect's matching criteria are pretty bulletproof so it won't randomly backup everything without some other cause. The test I asked you to perform was to verify that the matching was indeed functioning and to see if your editing software was changing files somehow so they get backed up.

 

 

 

Rather than backup the entire drive try it with a single subvolume or a test set of Data. If we can establish that Matching is working then we can look for other causes.

 

 

 

Thanks

 

Nate

 

---

 

 

 

* * * * * I'll try this on a smaller folder as you say, but I can assure you that my software is not changing the files. One of the main criteria and features of my Pro Audio Software (Digidesign's Pro Tools) is Instant Recall, the ability to come back ANY time and call up a mix of a song you did a year ago and be able to work on it right away. If it was doing this, about a million users would be screaming to fix it.

 

 

 

Add to this the fact that this issue (Retrospect wanting to start from scratch) has only occured a couple of times, maybe three. So DST would be a likely culprit since I work year-round like most people. But it always involved firewire drives and me moving the backup file drive from Internal to External, and connecting it via firewire. So:

 

 

 

1.) Are you saying that THAT was probably NOT the cause of this (the moving of the drive containing the Mac Backup File from internal to external firewire)? So Retrospect is not somehow going "Mmmm, this is not an internal drive anymore, it now appears on the Firewire chain and I must ignore it and re-backup."?? By the way it did not help to move the drive back inside the Mac.

 

 

 

2.) And you seem to be saying that my backups will be okay to RESTORE from, just not ADD TO if DST rolls around in the meantime. So I need to label ALL my backups as to the time period they were done in?

 

 

 

Now then. Does this not bother anyone? Aren't there a lot of Mac users that want to add to projects? What happens if I start a project a week before DST and it carries through. After 2 AM on the day, Retrospect is going to start from scratch the next time I try to incrementally backup???

 

 

 

Not a problem if we're just talking a bunch of Excel files or Word files. But 24 bit 44.1 Khz audio files take up Gigs of space.

 

 

 

Can't you guys fix this?? Or should I have my Mac ignore DST? Everyone wants their computer to be on the correct time. It just seems really BASIC to have Retrospect observe this.

 

 

 

Thanks

[shadowspawn 0]

A few notes:

 

 

 

1) The community-based forum is not an official means of contacting Dantz support, from Welcome to the Forum

 

 

 

Knowledgeable and helpful Dantz staff do contribute enormously, but despite any impression you got from your phone call, this is "only" a community forum. (The phone people were probably just trying to make sure you knew the alternatives to paying for a support call.)

 

 

 

2) Shifting how/where your drive is connected should not cause problems with a file backup set.

 

 

 

3) Daylight savings should not cause problems with a restore.

 

 

 

4) Daylight savings does cause a (bogus) full backup. I think these days it is probably a deficiency in Retrospect rather than the file system. For regular backups the positive spin is that it is a good opportunity to start a new backup. For when you just want to get the changed files, it is a pain!

 

 

 

5) I have not tried fooling Retrospect into believing the time settings are compatible, but it sounds reasonable. Did you change the date before launching Retrospect? I am wondering if changing the date while it was running was ineffective.

[Mayoff 124]

I have had several conversations with our engineers and we do need to and will be making changes to how the Mac and Windows products handle time zones and DST. These things will change, but for now Retrospect will work the same way it has for 15+ years when DS happens.

 

 

 

If the OS changes a file during the DST changes, then Retrospect will be forced to back it up. We will continue to work with Apple to get the error bug fixed for files modified on the day of DST.

[rtcstudio 0]

Quote:

---

A few notes:

 

1) The community-based forum is not an official means of contacting Dantz support, from

Welcome to the Forum

 

Knowledgeable and helpful Dantz staff do contribute enormously, but despite any impression you got from your phone call, this is "only" a community forum. (The phone people were probably just trying to make sure you knew the alternatives to paying for a support call.)

 

---

 

* * * * * * Yes, I got the corporate line from Mayoff in another thread. I realize now that no one at Dantz is obligated to help me here although now that I don't need help, it is coming quite regularly. Also it was not an "impression" that I got from Customer Service because I asked specifically about the frequency of actual techs reading this forum. I still say that they need to address this in the next company policy meeting, to make sure that people are aware that it can take over a week for a response. Those words need to be used "over a week". At that point I would have either paid the tech support fee, or upgraded in order to talk to a human. Some questions are not time critical, mine was. * * * * * *

 

Quote:

---

 

 

2) Shifting how/where your drive is connected should not cause problems with a file backup set.

 

3) Daylight savings should not cause problems with a restore.

 

---

 

* * * * * * These are good things to know. Thanks * * * * *

 

Quote:

---

 

 

4) Daylight savings does cause a (bogus) full backup. I think these days it is probably a deficiency in Retrospect rather than the file system. For regular backups the positive spin is that it is a good opportunity to start a new backup. For when you just want to get the changed files, it is a pain!

 

---

 

* * * * * * Again, Retrospect should have a preference to either OBSERVE or IGNORE DST. I have just upgraded to Ret 6.0 for Mac and looking through the manual I don't see anything encouraging on this issue. The DST issue is STILL not even addressed in the manual, only the Time Zone issue.

 

I appreciate your "positive spin" but when we're talking about the massive amounts of time to RE-backup an audio project, it is a total down day, and I mean in terms of doing a paying session, or taking an entire day to address Retrospect's deficiency.

 

I don't need a new backup, I make three of every project, two on removable drives and one on Sony AIT tape. So this is triple the pain in the....well, you know. * * * * * * * *

 

Quote:

---

 

 

5) I have not tried fooling Retrospect into believing the time settings are compatible, but it sounds reasonable. Did you have Retrospect running when you changed the date, or change the date and then launch Retrospect? (And I assume all the backups are of local disks?)

 

---

 

* * * * This was the only idea I got from the manual and the Knowledge Base or FAQ (which is basically a copy of the manual Trouble Shooting section). The manual says it works for Time Zone changes but says nothing of the DST issue.

 

It does NOT work in either of the scenarios you described. I think that if the Mac OS is physically rewriting the time stamp on the files, then there is no way to fool it. The only reason the Time Zone thing works is that Retrospect starts up, checks the clock and then sees that the files are not synced. Changing the Time Zone back would work in this instance, assuming that the Mac OS has not 'seen' a Daylight Savings Time change at which point you're toast.

 

One question still not answered: Is the Mac OS IN FACT scanning the drives on boot up and physically rewriting the inception dates before the drive shows up on the desktop??

 

Lastly I must reiterate: Dantz knows about this, and needs to fix it. I need to be able to go back to a project ANY TIME and change/add to AND INCREMENTALLY back up, without down time to accomodate Daylight Savings Time.

 

Thanks a mil' for the post, some of my fears are relieved.

[rtcstudio 0]

Quote:

---

I have had several conversations with our CTO and we do need to and will be making changes to how the Mac and Windows products handle time zones and DST. These things will change, but for now Retrospect will work the same way it has for 15+ years when DS happens.

 

If the OS changes a file during the DST changes, then Retrospect will be forced to back it up. We will continue to work with Apple to get the error bug fixed for files modified on the day of DST.

 

---

 

Thanks for the post.

 

So...You've known about this for "15+ years" and didn't consider it significant enough to FIX??? Your second sentence above suggests that I should just deal with it, and get over it.

 

If it's been this way for "15+ years", then PRINT THE ISSUE IN THE MANUAL or IN THE KNOWLEDGE BASE or IN THE FAQ.

 

I could have saved three days of waiting on a response here, massive frustration and worry, and HOURS of switching drives in and out of my computer, changing system clocks and rebooting numerous times, and posting in other pro audio forums about this issue. Is there a reason that you have NO reference to this problem in any of your printed or online documentation??

 

And this brings up another point. You would have charged me $70 to buy an incident support session to find out that this is a KNOWN pre-existing condition between Retrospect and ALL computers made? This would have been a 2 minute call to save me days of frustration. There needs to be some middle ground between Primo Pay Tech support and this forum. Or you could just document these things as I've stated above.

 

I can't believe this has all been over a known yet undocumented (at least not publicly) issue with no fix in sight. Is there a reason I shouldn't immediately warn all my Pro Audio customers/collegues about this bug?

[shadowspawn 0]

Quote:

---

One question still not answered: Is the Mac OS IN FACT scanning the drives on boot up and physically rewriting the inception dates before the drive shows up on the desktop??

 

 

---

 

No, not these days. (Assuming you are running Mac OS Extended format drives, also known as HFS+.)

[Mayoff 124]

Actually we have several KB documents and notes in Read Me documents

 

http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=26680

 

http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=27881

 

http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=26685

 

http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=27306

[rtcstudio 0]

Quote:

---

Quote:

---

One question still not answered: Is the Mac OS IN FACT scanning the drives on boot up and physically rewriting the inception dates before the drive shows up on the desktop??

 

 

---

 

No, not these days. (Assuming you are running Mac OS Extended format drives, also known as HFS+.)

 

---

 

Shadowspawn,

 

Then why am I having this problem? I am using Mac OS 10.3.2 and HFS+. If the OS is not changing my inception dates, what's the deal? Is Retrospect syncing to the new Daylight Savings Time on the computer and then somehow getting out of sync with the backup? How does it know to "get out of sync" since it hasn't seen the backup in 5 months?

 

I am now still confused as to why DST would cause this problem if your answer above stands.

 

Thanks for the help.

[rtcstudio 0]

Mayoff wrote:

 

Quote:

---

Actually we have several KB documents and notes in Read Me documents

 

 

 

---

 

Which are easy to find once you know that the problem is Daylight Saving Time and can use that as a search term. Try searching NOT knowing that and putting terms like "recopy", "Retrospect does full backup", "backup file ignored", etc. and see if those articles appear. Again, there is nothing you can say to make up for the fact that this issue should be in the manual in the same section as the Time Zone issue.

 

However, in fairness, I stand corrected. You do have articles in the Knowledge Base refering to this issue.

 

I have the brand new Retrospect Backup User's Guide for Macintosh version 6.0.178 for OSX. In the index there is nothing in the D's about Daylight Savings Time. If you look under "TIME" you get the same Time Zone explanation that was in my old 5.x manual. Nothing about Daylight Savings Time.

 

I inserted the install CD, expecting to find something there. Nothing. None of the links in the readme got me to any of your sites (I didn't spend a lot of time, and did not read anything older than version 5.x docs).

 

Here's my favorite excerpts from the sites you listed:

 

"While this issue may seem inconvenient, a little bit of preparation can make this a painless transition.

* Use this as an opportunity to rotate your media. Part of any comprehensive backup strategy involves periodically rotating old media out of service and bringing in a fresh set. Because Retrospect is going to back up all the files anyway, obtain a fresh set of blank media and have Retrospect perform a new backup.

 

* Take advantage of the weekend. If you wait until Monday to change the Daylight Savings time option, you might not have enough time overnight to complete the backup. The main inconvenience of backing up everything is the amount of time it takes. Most networks will be less active Saturday night when the time change occurs because their offices will be closed. Use this opportunity to change the computers' time settings on Friday evening and start the backup. Chances are, all your computers will be backed up by Monday morning."

 

* * * *You've got to be kidding. This is like a car's owner's manual saying "I know this car won't go in reverse at certain times of the year, but if this happens to you, take this opportunity to stay home with the kids, or to go somewhere you've never been before..." Add to that the fact that I have to keep feeding tapes to my AIT drive all weekend?

 

As I said before, I don't need a new backup, I make three of every project. Besides don't YOU think that 5 months is a little soon to have to "rotate media"???? * * * * * * *

 

And this one:

 

"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 forward a resolution."

 

* * * * *So 15 years later and how many operating systems? If Apple is not going to change their OS (why would you not want an OS to switch to Daylight Standard Time??) then why can't Dantz simply add a feature to Retrospect to Observe or Ignore DST?* * * * *

 

Mayoff, all your posts seem to do is to defend Dantz's position on everything. Even the sites you listed do nothing to further this discussion, only reiterate old information that we now know. Again I would like to know at what point the OS rewrites these inception dates. If it is not done at bootup as Shadowspawn has said, then when is it done? I merely hooked up the three drives: the two session drives with the project files on them and the backup drive with the Mac File Backup. At what point do things get out of sync if it's not at bootup??? If it's not as simple as adding a feature to Retrospect to ignore this or observe this, can you please tell me what's going on?

 

At this point, what I have gleaned from this discussion is that this issue is here, and will happen EVERY time I go back to a project that is not in the right DST window. Is this correct?

[shadowspawn 0]

Quote:

---

Then why am I having this problem? I am using Mac OS 10.3.2 and HFS+. If the OS is not changing my inception dates, what's the deal?

 

---

This is only my opinion and informed guesswork, don't take this as gospel.

 

My expectation is that Retrospect stores a single modification time for each file, perhaps implicitly in current local time. There is likely to be some historical complications based on what was available when Retrospect started, and there are certainly some modern complications too.

 

On HFS+ the internal representation of the modification date is in GMT. However, when an application asks the operating system for the date through any normal API what it gets back is in local time, since this is what the user expects. So after a daylight saving change, Retrospect gets back a different answer for the modification time (although nothing about the file has changed on disk).

 

Although asking for the modification date is a simple question, it is surprisingly complex to answer. Leaving aside even what the "right" answer is, in practice the modification date returned for a file may depend on the operating system of the file server, format of the hard drive, time zone, daylight saving, etc. Some combinations are smart and try to return an answer based on the daylight savings at the historical date, rather than based on the current date. Some return the GMT-based time in local time (e.g. HFS+ with Mac OS X). Some actually patch the times on disk when the change is first noticed (e.g. Mac OS 8.1).

 

This affects other applications too, cvs has ongoing fun and games because of the same issues even just on Windows ( Beating the Daylight Savings Bug ).

 

So while I am disappointed Retrospect does not do better on MY configuration, which is after all simple and obvious to me, there are some hard issues.

[rtcstudio 0]

Shadowspawn,

 

Thanks you so much for your informative posts. Dantz should hire you!

 

I only hope that someone from Dantz could chime in and fill in the blanks that you are so astutely providing. I will for now assume:

 

1. Right now and for the forseeable future, Daylight Savings Time is going to screw up my long term backups, and I should be ready for it.

 

2. It's more complicated than I think (although 15 years and the combined expertise of Apple Corp. and Dantz should be more than enough to figure something out).

 

Thanks again for taking the time to explain things to me.

[natew 0]

Hi,

 

This may be a bit simplistic but here it goes:

 

How does Retrospect tell the difference between a modify date that changed because of daylight savings rather than an actual modification to the file?

 

I think the answer is it simply can't. At best we could tell Retrospect to ignore changes of exactly one hour on files modified on the day daylight savings kicks in. That leaves Retrospect wide open to not back up files that have legitimately changed.

 

After daylight savings the file does not retain any of the date change nformation in its attributes. The file system just knows to change the time on all files by one hour. It doesn't track the changes file by file.

 

Hey, I completely agree this is a huge pain and a full backup involves a _ton_ of time and effort. It is truly aggrivating that such a simple problem can be so complex to try and resolve.

 

Nate

[cahaverl 0]

This foolishness also affects the latest Windows version 6.5 (I have 6.5.336).

 

I find it hard to believe that Win XP Pro doesn't store the modification dates in UTC. For what it's worth, I have NTFS system disks and a FAT32 firewire external backup disk. If Windows doesn't get the daylight savings change right, one would think it would affect both disks the same. A more likely conjecture is that Retrospect is comparing a Journal file to the date on disk. Perhaps the Journal file is not in UTC.

 

I haven't actually written a test program for fstat on Windows...

 

Retrospect's failure here would be less of an issue if it weren't so slow to do backups. It seems to eat up several orders of magnitude from the speed of my external disk for large file copies.

[natew 0]

Hi

 

Fat32 Stores the file dates the same way HFS for macintosh does. NTFS stores dates the right way, based on UTC.

 

That being the case you can get different time stamps for files on the same machine depending on disk format.

 

Thanks

Nate

[rtcstudio 0]

Basically, while there have been some informative posts, and some irritating ones, I see nothing here to supplant the following conclusion:

 

Dantz will blame Apple/Apple will blame Dantz

 

Dantz will blame Microsoft/Microsoft will blame Dantz

 

And this has been going on for "15 years".

 

Meanwhile, my only option is to turn Daylight Savings Time OFF in my main computer.

 

As complicated as it has been purported to be, there should be a fix. A long term backup should be JUST THAT: Reliable in the long term, for whatever I want to use it for. There should be a disclaimer sticker on every piece of Retrospect software that warns the user of this phenomena. There is nothing that the normal user can see to bring this situation to light, to make it obvious. It is barely refered to in the buried articles referenced in an earlier post.

 

This type of BUG should be noted before every download, or before EVERY sale. But then, that would cut into profits, I suppose.

 

What is done now is to basically use a euphanism and call this a PERK of Retrospect: That it MAKES you recycle your backup media. That's putting a new spin on a "feature" that all of us would rather do without.

[derrickbass 0]

Quote:

---

How does Retrospect tell the difference between a modify date that changed because of daylight savings rather than an actual modification to the file?

 

I think the answer is it simply can't. At best we could tell Retrospect to ignore changes of exactly one hour on files modified on the day daylight savings kicks in.

 

---

 

This is not true. At least, not for HFS+ disks. The modification time is stored as UTC on the disk (UTC is the modern name for what was once Greenwich Mean Time). The time you see displayed in the Finder is converted on the fly according to your current time zone and daylight savings time preferences.

 

Now when Retrospect was invented, this was not case. HFS stored dates in local time. Mac OS, as far as I know, still supports the old ways of getting the file date (this is one reason why really old programs still work). However, there are ways to get the date in UTC! Even if Carbon (the current incarnation of the old Mac OS system calls) does not support this (although I'm 99.9% sure it does), the UNIX calls do allow you to get the date in UTC (as this is how UNIX has always worked).

 

I am going to guess that Retrospect's method of learning the modification date of the file is based on the old system calls and has never been updated. If so, this is definitely a retrospect problem. It may be very difficult to fix. But it is still Dantz's fault.

[rtcstudio 0]

Quote:

---

 

Now when Retrospect was invented, this was not case. HFS stored dates in local time. Mac OS, as far as I know, still supports the old ways of getting the file date (this is one reason why really old programs still work). However, there are ways to get the date in UTC! Even if Carbon (the current incarnation of the old Mac OS system calls) does not support this (although I'm 99.9% sure it does), the UNIX calls do allow you to get the date in UTC (as this is how UNIX has always worked).

 

I am going to guess that Retrospect's method of learning the modification date of the file is based on the old system calls and has never been updated. If so, this is definitely a retrospect problem. It may be very difficult to fix. But it is still Dantz's fault.

 

---

 

Hey Mayoff, care to respond to this? Anybody at Dantz? Or should we just go another "15 plus years" (Mayoff's words) being grateful for what features we already have?

 

I think this is a LOW priority to Dantz. I don't think they think it is a problem worth fixing. Just recycle your media and leave them alone. They've known about it for over a DECADE and have not bothered to correct it.

 

For my part, I've turned OFF daylight savings time on my $3500 computer. When people ask, I let them know that Dantz can't figure out how to make Retrospect work correctly.