Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About rtcstudio

  • Rank
    Occasional Forum Poster
  1. rtcstudio

    One folder repeatedly backs up

    "Ignore Ownership" is not checked. Retrospect 8 is basically all the beginning default settings, except I have it set to back up "All Files", but not to overwrite identical older files. So just an incremental copy. I'm using the Copy (used to be "Duplicate") function. 2 drives, firewire, Master connected to computer via firewire 400, the Copy drive connected to the Master firewire 400 port. Mac OS 10.5.8 THis has never happened on another set of drives. Other projects are working as you would expect, just copying anything new in the incremental way. Never seen Retrospect continue to want to back up a folder over and over, even seconds after RE-backing up. TODAY I ERASED the offending folder from the copy drive, moving it to the trash and emptying the trash. I then started Retrospect and ran the copy script for these two drives. Of course it recopied the folder, since it was gone from the copy drive. After a successful backup, I closed Retrospect, and then opened it again. I ran the copy script again and IT STILL recopied the folder! If there are other settings you would like me to check, I'd be glad to do it. Thanks for the replies. Maybe I should try a brand new copy drive? Or erase/initialize the copy and re-do the entire copy?
  2. rtcstudio

    One folder repeatedly backs up

    I think there is some attribute(s) that Retrospect is not matching as being identical. And the fact that the same thing happened in 6.1 suggests that 8.1 is also doing the right thing. Have you used any file comparison utilities to list all the attributes of the folder/files on each volume (sizes, dates, POSIX, etc) to see what the difference might be? Maybe Russ can provide a nice shell script or suggest an existing application. Dave I guess I don't see how Retrospect works. It seems like to me, that the first time it re-copied the folder at issue OVER the other folder on the copy, that from then on the files would be identical - they are copies after all. I just don't see how Retrospect can keep seeing the very same folder as different in some way, and need to be backed up. Would it help if I physically deleted the folder on the copy and then ran Retrospect again? Perhaps that would nuke anything that was causing a difference to be consistently seen?
  3. rtcstudio

    One folder repeatedly backs up

    Both are Mac OS Extended (Journaled). Both are connected to the Mac Pro via Firewire 400 (well, the master drive is connected to the Mac Pro, and the safety drive is connected to the master drive. Never had a problem with this before) Local, not network. Thanks!
  4. This happened in 6.1 as well. I'm on Retrospect 8.1 now. I'm doing the COPY function to copy one large project folder on a drive to another identical project folder on a 2nd drive. This works all the time as usual on other drives. On this particular project, there is a subfolder with about 1.6G of .wav files that ALWAYS re-backs up. I can run Retrospect, COPY and then a minute later run it again and the same folder will back up again! I can unmount the drives, repair permissions, remount the drives, re instantiate Retrospect and it will happen again. That one folder always copies over to the safety again! BTW these drives are both connected to the same computer, not on a network or anything. any ideas? Thanks! Mac Pro 2 x 2.66 Ghz dual-Core Intel 17 GB RAM Mac OS 10.5.8 7200 RPM Firewire Drives Retrospect 8.1
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. 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.
  10. 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?
  11. 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.
  12. 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
  13. 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
  14. rtcstudio

    Relying on Product When Errors Occur

    Quote: My heart sunk when I saw your posting;~/ It's dreadful that nobody has helped you on this matter in the timescale since your posting, not even a Dantz sysop... One has to wonder just how much assistance, and just how valuable, am I to exprect is going to be available herein. best wishes, Robert Unfortunately Mayoff, one of the administrators, has made it clear in another thread (one of yours Robert, the "anybody here?" thread) that no Dantz employee has to respond to us at all. I waited 8 days for a response which contained no possible solution. The response only asked me to run hours (and I'm talking literal days) of tests to see if something would happen. If you want quick tech support, it has been made abundantly clear that you will have to pay for it.
  15. 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.