Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About derrickbass

  • Rank
    Occasional Forum Poster
  1. derrickbass

    Won't unhide

    Quote: >I have filed bug reports for the (extremely serious) lack-of-verification bug against >every version of Retrospect I've owned since I first discovered the problem in the late 1990s! While this behavior could reasonably be considered to be ill-conceived, it is not a bug. The program is behaving the way it was designed to; it's the design that you feel is deficient. The engineers know how it works, so it would be the marketing department that would be keeping track of customer dissatisfaction of particular features (or lack thereof). Well, since I've never heard back from Dantz, I can't say whether or not this is the designed behavior or simply a bug (or, more likely, an omission). (I can't really tell whether you are making a supposition or a definitive statement.) However, even if this is a design flaw, I think it is a flaw is so serious that it merits being considered a bug, because Retrospect is failing to do something that reasonable people expect a backup program to do. Anyway, now that EMC has assimilated Dantz, maybe another bug report is in order. Quote: > I've never reported the WindowServer bug because, well, frankly, what's the point? Dunno, but while WindowServer is often sucking up more cycles then I'd like during general computer use, on my system (iMac G5/FWexternals/FileBackupSets) I don't see any particular increase when Retrospect is running, scanning or copying. Lots of cycles for Retrospect itself, true. But I see Safari being more of a problem with WindowServer then I do Retrospect. Your milage certainly varies. Maybe it's the differences in our video systems. But if it's reproducible it's probably a software defect. Maybe. My computer is also quite slow compared to yours. It may be that Retrospect is updating its window at some very high rate that is having a detrimental effect on my computer, but yours is fast enough to keep up with. Okay, you've convinced me to file a real bug report on this one. Quote: >I was just hoping someone on the forums had seen the bug before and would know >whether I can get around it. I have. Probably back with 5.0x or 5.1. But I seem to recall that the Retrospect menu bar was in place, but I could be mistaken. It was a couple of years ago, and I haven't seen it since. Although Apple took the hardware eject key away, the OEM manufacturers of the drives around that time still had them in place. Perhaps a well placed paper clip might trigger the vestigal switch? This did occur to me. But from what I remember the last time I had to use the little button, not only did it not fix whatever program was using my drive, but the drive became non-functional until I rebooted. Inserting disks simply didn't work. I'll wait a day or two and see if anyone has another suggestion and then I'll try it. By the way, I did try the keyboard's eject key; although the nice "eject" icon appeared on the screen, the disk stayed in the drive. I'm sorry for ranting at you. I know it's not very constructive, but years of frustrations with Dantz's lack of support and communication just got to me. I should not have taken it out on you.
  2. derrickbass

    Won't unhide

    Oh, hey, I just remembered. There was one bug that I reported that actually got fixed. It took about 4 years, but it did get fixed. Of course, it was a paid upgrade, but Dantz wasn't the only company that felt it appropriate to make people pay for bug fixes. So I guess reporting bugs isn't entirely useless. (The bug, by the way, was Retrospect's inability to back up files with certain unusual characters in the name. I think ñ was one of the problematic characters. Anyway, it was finally corrected in 6.0. or 6.1 or something like that.)
  3. derrickbass

    Won't unhide

    Quote: As you note, there seem to be some windows in Retrospect that, once they are no longer in front, cannot be easily be brought back (the login window is one). I've always been able to use Exposé to show all windows and find the right one. If you haven't changed the system defaults, the keyboard command is F9. It's not that the windows aren't in front. I hid them (with the "Hide" command). Hidden applications don't appear in Exposé. Ordinarily, clicking on the dock icon causes a hidden application to reappear, but that's not happening. (I guess I should point out that the cursor changes to the Retrospect moving-checkerboard cursor, but the menu bar doesn't change nor do Retrospect's windows appear.) I've also tried the "Show All" command and tried selecting the window from Retrospect's Dock menu. I also tried switching from one account to the other and then back again. I actually at one point suspected that Retrospect was actually unhidden, but stuck in the back somewhere. However, Exposé did not reveal its windows. I even hid every other application until I saw my bare desktop, but I never saw Retrospect's windows.
  4. derrickbass

    Won't unhide

    Quote: Describing undesired behavior from a software application is not the same as a bug report. The former is what you've provided. It's a drag when it happens, but it's only marginally helpful to developers. The latter includes a full description of the test bed, and complete, unambigious steps to reproduce. Why do you assume I haven't filed a bug report? I have filed bug reports for the (extremely serious) lack-of-verification bug against every version of Retrospect I've owned since I first discovered the problem in the late 1990s! I've never even gotten an acknowledgment that my report was received, nor has the bug been fixed. (Well, I skipped a few versions during the time when Dantz didn't even want bug reports unless you opened a paid support incident.) I've reported several other Retrospect bugs that I didn't mention above, and never got any response on any of them. Frankly, given that level of arrogance, as well as the clear implication that Retrospect simply cannot be trusted with my data unless I watch it like a hawk, I don't know why I even use it anymore. And why is this bug there anyway? I mean, good grief, who builds a backup program that assumes the data is GOOD until proven otherwise? Is it not common sense that the data should be assumed BAD until verified? The correct behavior would be to continue the verify where if left off and, if that was not possible, back up all the unverified data again. Okay, sorry for the rant, but having to report 8 year old bugs over and over and over again... well, I needed to vent. Anyway, I've never reported the "not ejecting the DVD bug" because it's trivial. It never really bothered me much before. It's only just now, because it's compounded by the other 3 bugs. I've never reported the WindowServer bug because, well, frankly, what's the point? The bug report will just go into a black hole like all the others I've sent. And finally, the unhide bug, as is perfectly clear from my post, is not reproducible. (I said that I "have taken to hiding Retrospect" which implies that I have done this before and the "Well, today" implies that this is the first time the problem happened. If I discover a way to reproduce it I'll consider filing a report. Maybe now that the EMC takeover is complete, the developers will take bug reports seriously.) I was just hoping someone on the forums had seen the bug before and would know whether I can get around it. I was not aware that the forums were an appropriate place for filing bug reports, but if you wish I can write up full bug reports for all the reproducible bugs I've discovered in Retrospect and post them here. Anyway, if you think it helps any... Retrospect 6.1.126, Driver update, Powerbook G4 500 MHz, Mac OS 10.4.5 (build 8H14), backing up a subfolder from an external FW hard drive to Memorex DVD+RW media on an internal Matshita UJ-825S with a custom driver created by Retrospect. This is the first time the issue has occurred, so I have no idea whether or not it is reproducible. But here's what I do... I periodically check to see how Retrospect is doing (since it can't seem to manage more than 10 MB/s... bug number 5) and then hit "Command-H" to hide it. Yesterday, it stopped coming back when I clicked on the dock icon. But it was still working away, backing up my 11 GB of stuff. I know because it kept popping out the DVD in order to ask for a new one, and I just kept putting in blank ones hoping I'd figure out how to get the GUI back before verification time came. But, alas, that time came and the Retrospect windows are nowhere in sight. Hence the posting.
  5. Because Retrospect causes WindowServer to take up large amounts of CPU and causes my computer to slow to a crawl, I've taken to hiding it while it is doing its backup, which seems to help. Well, today, it won't unhide. I kept inserting DVD+RW's as it needed them, but now it wants to verify the backup (I can tell from looking at the log) and for reasons never clear to me, it doesn't automatically eject the DVD that's in the drive when it begins a verify. So I need to actually click on the DVD and click the "Eject" button. So, how do I get Retrospect to come to the front? Or is my only hope to force quit Retrospect? I would hate to do that, because Retrospect has a long standing bug where if a backup is interrupted before the verify is completed, then the verify NEVER takes place! So I'll need to grab an old version the catalog off my backups and then do the whole backup again. By the way, I've listed 4 bugs here. Don't you folks at EMC think that's a little excessive?
  6. Quote: Hi If it is isolated to one backup set then chances are there is some corruption in the set. Can you use the backup set transfer feature to copy the contents of the problem set into a new set? Thanks, Nate Alas, no. I tried and got the same error message. I also tried rebuilding the catalog, which took several days , but that did not help. I guess there is some corruption in the set itself that is being transferred to the catalog file when I rebuild. I'm going to try and mark the last few disks as "missing" and see if that helps. Also, I made a copy of the catalog file after each disk was re-cataloged, so hopefully I can figure out which was the last good version and proceed from there, instead of starting a whole new backup set.
  7. It's just that backup set.
  8. Quote: Hi This used to work OK? Yes, but see below. The catalog was just rebuilt. Quote: Likely candidates are: Corruption in the catalog file. Corruption in the Retrospect preferences. Can you pull your Retrospect preferences and try a test backup to see if the problems continue? Thanks Nate Okay, I tried removing both the com.dantz.retrospect.plist file from my Preferences directory and the Retro Config 6.0 file from the /Library/Preferences/Retrospect directory. Is there something else I should remove also? I got the same error in the same place. I just noticed that Retrospect produces error logs when this sort of thing happens. I am enclosing one (and also posting a bug report). If it is catalog corruption, what could be causing it? I just rebuilt the catalog because I had to interrupt a backup in progress (and Retrospect has this incredible bug where if a verify doesn't happen the backup is assumed to be GOOD (really, it should just finish verifying; but barring that it should assume the members that were not verified were BAD). Moreover, there's no way to verify after the fact; you just have to rebuild!) I rebuilt the catalog not long before that because of another problem (Retrospect kept insisting that my new members were too different from the old members, even though they came out of the very same box of DVD-RWs). And not long before that, I had to rebuild because Retrospect decided to lock up during a verify (see stupid Retrospect behavior above). I really hate to have to rebuild again! This is getting ridiculous. It seems like I have to rebuild the catalog every 2 or 3 backups. Are other people experiencing this kind of behavior, or does Retrospect just hate me in particular? Here's the bug file: Retrospect detected a failure: This report documents an unusual condition detected by Retrospect’s internal integrity checking. This might be caused by a software bug, but can also be the result of an incompatibility, hardware malfunction, damaged system software, or other problems. Details on possible causes can be found on EMC’s website: http://www.emcdantz.com/support For further assistance, call us at (888) 777-5664 or (925) 948-9050. Please be prepared to provide us a brief description of the steps that led to this failure along with the assert log. --- Retrospect Problem Report date: 12/9/2005 1:00 AM version: 6.1.126 Internal consistency check failed: Assertion check at "elem.c-918" Stack Crawl... DATA_0000 +50a38 DATA_0000 +12e8fc DATA_0000 +2cc14 DATA_0000 +1dfc0 DATA_0000 +62674 DATA_0000 +58794 DATA_0000 +6288c DATA_0000 +62e7c DATA_0000 +63344 DATA_0000 +34588 DATA_0000 +88cfc DATA_0000 +34344 DATA_0000 +8d358 DATA_0000 +93048 DATA_0000 +34344 DATA_0000 +f626c DATA_0000 +f68a0 DATA_0000 +f71ac DATA_0000 +34344 DATA_0000 +a54ec DATA_0000 +5850 DATA_0000 +34344 DATA_0000 +13284 DATA_0000 +34344 DATA_0000 +3740c DATA_0000 +3753c DATA_0000 +34344 DATA_0000 +86fac DATA_0000 +34344 DATA_0000 +87e68 DATA_0000 +216a4 DATA_0000 +59ed4 DATA_0000 +5a0d0 DATA_0000 +21928 DATA_0000 +2cd04 DATA_0000 +59ed4 DATA_0000 +5a0d0 DATA_0000 +2ce60 DATA_0000 +59ed4 DATA_0000 +5a0d0 DATA_0000 +2cf58 DATA_0000 +2d0c4 ---
  9. Hmmm... I knew my post seemed much too short. How stupid of me: I'm running Mac OS 10.4.2 on a 500 MHz Powerbook G4, backing up an external FW DVD-RW drive (Pioneer DVR-105; natively supported by Retrospect; no need to create a driver). The computer is backing up its internal hard drive with Retrospect 6.1.126 and driver update (I had the same problem before driver update, btw).
  10. I just started getting an elem.c-918 error every time I try to do a backup. It happens on the "matching" phase. I couldn't find any reference to that error anywhere on the EMC/Dantz site. Any ideas?
  11. Well eventually I had just give up and Stop the backup. I'll restore an old version of the catalog from backup and then rebuild the set from there. Grrr...
  12. I just did an incremental backup after a pretty big upgrade; it took 12 DVDs. Anyway, Retrospect is stuck on the first DVD in the compare phase. There is obviously a problem with the disk. Lots of errors like this in the log: Trouble reading: “52-Backup Set C” (3101), error 206 (drive reported a failure: dirty heads, bad media, etc.). Trouble positioning: “52-Backup Set C” (3101), error 206 (drive reported a failure: dirty heads, bad media, etc.). and the number of files compared has not been updated in many hours. The trouble is, I can't hit stop because of the long standing bug that Retrospect has had since at least 1997: it assumes the backup is okay unless the compare proves otherwise. So... if I hit stop now, I'll have to abandon all 12 DVDs since there will be no way to verify whether they are really okay or not. Any suggestions on a less drastic alternative?
  13. Quote: This is a long standing problem with the way Macintosh filesystems keep track of times on files. Unfortunately we are stuck with it. Umm, no, it's a problem with Retrospect. It is trivial to determine the modification date of files in UTC. Every UNIX based backup program on the planet does that, and many of them work just fine on Mac OS X. The issue to which you refer was addressed by Apple with the introduction of HFS+, which stores mod dates in UTC. Now I can barely believe that this may have been a problem with Mac OS 9 (although I'm nearly sure there was a way to either get the date in UTC or to programmatically determine the time zone offset and therefore compute the UTC time). I can certainly believe that changing this might have caused some incompatibility betwen Retrospect versions. But Mac OS X has been out for a very long time now, and since then Retrospect has undergone at least one major version change (and maybe 2; I can't quite recall when Retrospect 5 came out). The change to version 6, in fact, changed the format of backup sets, so if dealing with this problem would introduce some incompatibility, that was the time to do it.
  14. Just thought I'd ping this post back up to the top to see if I get any responses a second time around. Is this a bug in Retrospect, or just something I alone am experiencing? Is there a workaround?
  15. I recently moved and now Retrospect wants to back up everything. Changing my time zone back to the original one confirms that the time zone change is what is causing Retrospect to think everything has changed. Is there any way around this bug? (I'm backing up to DVD-R on Mac OS 10.4.2 with Retrospect 6.0.212.)