Jump to content

DavidHertzberg

Members
  • Content count

    1,239
  • Joined

  • Last visited

  • Days Won

    41

Posts posted by DavidHertzberg


  1. Yesterday jhg started a new thread in this forum, in which he/she described error messages for several (newer?) files similar to those he/she reported for one file in post #1 of this thread.  I chided jhg for not having posted them in this thread, whereupon he/she reported his/her own post—requesting that it be deleted.  As is usual in such cases, Retrospect Support deleted the entire thread.

     

    But that belatedly spurred me to think of a new partial solution to jhg's "Backup Set format inconsistency" problem, derived from my further thinking (while taking a post-gym shower ) about what I wrote in the second sentence of the second paragraph of my post in the new thread.  It first occurred to me that, although he/she didn't mention his/her Retrospect version in post #1 in the new thread, he/she might have mentioned it in this thread.  jhg did, and—unless he/she has upgraded since 29 May—it's Retrospect Windows 11.5.  I know that that's not the latest version, and it next occurred to me to do a browser search for "Backup Set format inconsistency" in the cumulative Release Notes for Retrospect Windows 12.1.  Lo and behold, Retrospect Windows 12.0 has a Fixed line for "Clarified error for backup set format inconsistency (#5627)".  I don't know exactly what that Fix is, but it's likely that it at least will tell jhg the names of the files that have the inconsistency.  If it does, he/she can then do the trivial name change I suggested in post #2 in this thread—to cause each file (assuming jhg still has them on a disk somewhere) to be backed up again.

     

    jhg can contact Retrospect Sales to get a 45-day trial license for Retrospect Windows 12.1.  I expect him/her to give us other administrators the courtesy of posting the results of his/her trial, at least as to whether Retrospect 12.1 clarifies the message for "Backup Set format inconsistency" by giving the names of the files involved.

     

    I apologize to everyone for not having thought of looking in the Release Notes back on 29 May.  There's a reason why Retrospect Inc.'s Support Case form asks for the version of Retrospect the case filer is running; we should all remember—as jhg did in post #1 of this thread—to supply that information when starting a thread in these Forums.

     

    P.S.: To use the "new partial solution", jhg would have to (as I said in post #7 in this thread) "manually Run a Normal Backup for the Source onto the same Backup Set.  That, although it might backup some extra files if the Backup Set were not still in use, would result in a new backup of the [name-changed] file that produced the error."


  2. Apropos of what I wrote in the first paragraph of post #6 in this thread, I now notice that dzeleznik speaks in his/her Latest Status paragraph 2. in post #5 of "none of my crucial db's".  I assume that means that these are databases, and that dzeleznik has therefore enabled Retrospect's block-level incremental backup feature (pages 525-529 of the Retrospect Windows 12 User's Guide) for them.

     

    Curiouser and curiouser (said Lewis Carroll's Alice, for non-English speakers).  I wonder if the fix for bug #6668, which was supposed to fix "uncommon case of fast rebuild [my emphasis] misreporting block-level incremental backup chains as broken", created misreporting for verify runs—which iCompute is also talking about in his thread.


  3. iCompute should note that dzeleznik has now done some thorough testing of his/her Retrospect Windows 12.1 "chain broken" errors, and it looks as if this is a new bug in the latest version of Retrospect.  In the second paragraph of this post in that thread I have strongly urged dzeleznik to file a Support Case, since he/she has the material to do so.

     

    In the third paragraph of that post I have made the controversial suggestion that dzeleznik, who evidently upgraded to the latest paid version of Retrospect Windows within the last 45 days, should phone Retrospect Sales and ask for a refund of his/her upgrade fee—an expedient which will almost certainly bring the new bug promptly to the attention of Retrospect Support/Engineering.  I have also discussed the possible downside of doing that, so—if iCompute wants to also consider that expedient—he should read the full paragraph.


  4. Very interesting, because the Release Notes for Retrospect Windows 12.1 include the Fixed entry "Fixed uncommon case of fast rebuild misreporting block-level incremental backup chains as broken and not restorable (#6668)".  It sounds to me as though, assuming dzeleznik was not using Fast Catalog Rebuild, the fix for bug #6668 may have broken something else.

     

    In any case, IMHO dzeleznik should file a Support Case per post #3 in this thread.  He/she can easily adapt the contents of posts in this thread for the Description of Problem and Additional Notes.  He/she should also try to preserve log files etc., because IME Retrospect Support will ask for uploaded copies.

     

    Here's a more controversial suggestion: Since dzeleznik evidently upgraded from Retrospect Windows 11 to Retrospect Windows 12.1 within the past 45 days, he/she should phone Retrospect Sales and ask for a refund of the upgrade fee.  That's a very good way to get Retrospect Sales to make Retrospect Support and Engineering pay attention to the evidently-new "chain broken" bug.  Of course the downside of this strategy is that Retrospect Sales might call dzeleznik's bluff on his/her threat.  dzeleznik should therefore consider whether reverting to Retrospect Windows 11.5 would deprive him/her of bug fixes that he/she really needs; IMHO most non-Cloud-using Retrospect administrators don't really need the New features or Improved features in Retrospect Windows 12.0 and 12.1.

     

    I'll make a post in iCompute's thread in the "Retrospect 9 or higher for Macintosh" forum, suggesting that he look at the third paragraph in this post and consider also phoning Retrospect Sales.


  5. Per the second paragraph of this post, jrpsupport can get a 45-day free trial of a newer version of Retrospect.  I don't know whether Retrospect Inc. would insist on selling him/her an upgrade to Retrospect Mac 14, or whether he/she could get a reduced price on an upgrade to Retrospect Mac 10—which would allow a free upgrade to Retrospect Mac 10.5 to get the #3961 bug fix.


  6. I hate to say it, but the fix is likely to cost jrpsupport's installation some money (insert appropriate smiley here).  If he/she searches the Release Notes for a recent version of Retrospect Mac, under "10.5.0.145" he/she will see the Fixed entry "Fix date and time in email header (#3961)".

     

    This post by iCompute confirms that his bug was fixed in Retrospect Mac 10.5.  The preceding 16 posts in that thread discuss problems administrators were having with the bug in 2012-2013, and post #15 in that threat by Retrospect Inc.'s Director of Product Management says "Specifically regarding the standard Date: field in email header and therefore used by various email client software, the 3 issues above are fixed in the next free update.".  I don't know how jrpsupport's other Mac Server installations of the "backup server" have avoided having the problem thus far.


  7. dzeleznik reported the same type of error for the latest version of Retrospect Windows in this post in the Windows Products—Retrospect->Professional forum.  As I said in my first post in that thread, one of the two of you had better file a Support Case.  As my second post in that thread, I posted my usual boilerplate explanation of why and how to file a Support Case; therefore I won't repeat it in this thread—especially since iCompute has probably already seen it. 


  8. If you think this is a bug that should be fixed by Retrospect Inc., you will have to submit it as a Support Case.  For English speakers, that is done by going here http://www.retrospect.com/en/support/contact, and filling out the form (sorry, I don't know what the equivalent addresses are for non-English speakers, but they can figure it out from their appropriate Retrospect website address).  IMHO this is quite reasonable; obliging you to fill out the form provides Retrospect Inc. with useful details about your Retrospect installation that they would otherwise have to query you for.

     

    As a result, Retrospect Inc. will pay no attention to your post in this forum.  On 12 December 2016, in response to a letter I snail-mailed to Mayoff,  I received an e-mail through a Mayoff account that was signed by JG Heithcock, CEO, Retrospect, Inc. http://www.retrospect.com/en/about#exec.  In it he says "From reading your letter, I think the main issue is that you view the forums as a good place to talk to us, Retrospect, Inc. But we view the audience of the forums as restricted to our customers [my emphasis]. The one caveat we have made on that is for feature requests, largely as we would like to see if other customers also agree on the desirability and feature set for these requests."

     

    That means that the only audience for "Retrospect bug reports" in this forum will be other administrators of Retrospect.  Nevertheless, by posting in this forum you are providing a useful service to us fellow administrator peasants.  Thank you.

     

    Please be aware that the "description of your issue" in the Support Case form is IME limited to about 2000 characters by the Support Case software.  If you go over that limit your "description" will be broken up into a "description" plus one or more "additional notes".  The same is true for any additional notes you may later post yourself.  I suggest that, to avoid the appearance of choppiness in your Support Case, you create your case in a post in this forum and then copy it paragraph-by-paragraph to your Support Case. 

     

    Note that, despite the new dialogs in the Retrospect Inc. Support Case system urging you to sign up for Annual Support and Maintenance, Mayoff has verbally assured me that you don't need to be signed up for ASM to report a bug—only to get personal assistance with coping with it.

     

    If this post sounds formulaic, that's because I intend it to be.  I intend to post it in every new thread that appears in this forum, unless the OP either is merely asking for help or indicates that he/she has or will open a Support Case for the bug that the thread reports.  Of course, Mayoff could take 5 minutes of his time to post a slightly-more-polite version of this post as a  "sticky thread" that will always appear at the top of the forum.  I don't intend to hold my breath until that happens (insert appropriate smiley here).

     

     


  9. dzeleznik is not the only one getting this error on the latest version of Retrospect, even though that other person is a Retrospect Mac administrator.  See this post.

     

    I found that post by clicking on the gear icon at the top right of the Web page, on the same line that says "IPS Community" on the left.  That gave me Advanced Search, and I typed "chain broken"—including the quotes—into the Find Words box.  I did not select anything in the Find in Forum dropdown, but just clicked the Search Now button.

     

    My next post in this thread will be my boilerplate explanation of why and how to file a Support Case.  Since dzeleznik and iCompute are both getting the same error in similar circumstances on what is—under the hood—the same new version of Retrospect, one of the two had better file one.


  10. On 7/30/2017 at 9:55 PM, Roger Fajman said:

    I thought I posted this before, but it's not here. I decided to upgrade to 11.1 and find it to be much more reliable. It doesn't get those file/directory not found errors all the time. It's a problem that existed for years, over many versions. It looks like they finally fixed it. It shouldn't take an upgrade to get a fix for something like that...

     

     

    OK, let's all cross-post 🤣.

     

    Roger Fajman didn't need to post this, because he's been beaten to the punch by Johnny Mac in this post.  However post #1 in this thread says Roger Fajman was already using Retrospect Windows 11.5, so I think he has actually upgraded to Retrospect Windows 12.1—whose Release Notes says it contains a couple of fixes for the -1101 error (insert appropriate smiley here).  Anyway it's nice to know that both administrators' -1101 errors have been fixed. 


  11. I thought I posted this before, but it's not here. I decided to upgrade to 11.1 and find it to be much more reliable. It doesn't get those file/directory not found errors all the time. It's a problem that existed for years, over many versions. It looks like they finally fixed it. It shouldn't take an upgrade to get a fix for something like that...

     

     

    Roger Fajman didn't need to post this, because he's been beaten to the punch by Johnny Mac in this post.  However post #1 in this thread says Roger Fajman was already using Retrospect Windows 11.5, so I think he has actually upgraded to Retrospect Windows 12.1—whose Release Notes says it contains a couple of fixes for the -1101 error (insert appropriate smiley here).  Anyway it's nice to know that both administrators' -1101 errors have been fixed. 


  12. I now have an explanation for the "anti-miracle" I referred to in post #7 in this thread, and probably also for some of the problems saskia is having.  I was tipped off to it when I looked at this Cult of Mac article, which is linked to from Retrospect.com's own Press page.  The article—which is about Retrospect Mac 14—is "Sponsored", which evidently means that Retrospect Inc. itself essentially wrote it.

     

    The article says "Speaking of integrations, the Mac version of Retrospect now features the same script hook functionality as the Windows version."  And, by Gadfrey, the bottom of the Knowledge Base article linked to in posts #4 and #7 in this thread says "Last Update: January 27, 2016".  Sure enough, there is an "External Scripting" section starting on page 488 of the Retrospect Windows 11 Users Guide; in case you didn't know, Retrospect Windows 11 is a now-obsoleted version released in early 2016.  The same section now appears on page 484 of the Retrospect Windows 12 UG, which is the current version.

     

    So script hooks are not new for Retrospect Windows, only for Retrospect Mac 14 and only the term "script hooks".  IMHO this means the Retrospect engineers probably only tested the Retrospect Mac script hooks for Mac clients—and probably not that thoroughly, and didn't also test whether script hooks for a Mac "backup server" Engine would also work with Windows clients.  It also explains why the .ZIP file linked to in the Knowledge Base was only updated on the evening of 20 July 2017, and likely updated in a hurry—which IMHO would explain why the free-standing sample_sh file was deleted instead of receiving any necessary revisions.


  13. In my Support Case, there followed several exchanges of Additional Notes yesterday, following Retrospect T.S.'s request the day before yesterday that I upload my operations_log.utx file and a copy of any applicable screenshots.  I'll spare you these Additional Notes, since they are Retrospect-Mac-specific and this is a Retrospect Windows forum.

     

    However IMHO my last Additional Note is worth reporting (slightly abbreviated), since it is of more cross-platform applicability.

     

    "Following up on the Agent Response of July 27, 2017 12:27:


    As mentioned in the second paragragph of my Description of Problem of July 26, 2017 03:17, I already did what you suggested. The trap for others is that Sources—>Add—>Options defaults to All Volumes, including the 'phantom disks'.

    The 'phantom disks' may in fact be the result of a new wrinkle/bug in macOS 10.12.6, since I don't recall having this problem when David's MacBook Pro was booting under OS X 10.10. The machine had a new SSD installed, to replace a failed HDD, about 3 months ago by ...; at my request they installed macOS 10.12 on the SSD. I then ran Setup Assistant [a facility of macOS] to put back all other files from a portable HDD onto which I had done a Retrospect Restore of the latest Backup of the HDD. I haven't done anything since except a couple of upgrades, including to macOS 10.12.6.

    I'm sorry if Apple has made life difficult again for Retrospect Inc.. But IMHO you'll have to change Retrospect Mac to compensate for that.
    "

  14. Message from Support:

    We have reproduced the issue with the external scripting and we have written a bug for the problem.  We hope to fix this in our next update. 

     

     

    Congrats, saskia.  

     

    You might consider adding to your Support Case—which I assume you have already created—an Additional Note requesting that Retrospect Support add back to the .ZIP file archive mentioned in posts #4 and #7 in this thread the stand-alone sample_sh Bash file that used to be there.  If they could add additional comments explaining the arguments for the functions, that would be great.

     

    When you get your Bash shell script fully working, you might consider making it available to those of us Retrospect Mac administrators who don't want to use IFTTT or Slack to monitor the results of complicated combinations of Backup scripts.  You might even consider charging money for it, especially if you can develop a version that would work for Retrospect Windows administrators, although I doubt it would make you independently wealthy (insert appropriate smiley here).

     

    BTW, folks, when copying from other documents—such as e-mails or Support Cases—into Forum posts, your pasted text will frequently end up in a smaller-size font.  See, for instance, Saskia's post #13 in this thread.  The way to counter this is to select the pasted text, and then use the Font and Size dropdown in the Forums editing window to change the pasted text to font Arial and size 14.  I did that to the quote from post #13 at the top of this post.


  15. The last paragraph of the "description of your issue" in my Support Case (the rest of it was essentially a duplicate of the second and third paragraphs in post #6 in this thread) read:

     

    "Why are these 3 _other_ Retrospect-detected volumes showing up? They have long hexadecimal-number names.  Are they some artifact of my client's SSD drive, which was installed about 3 months ago to replace a failed HDD? Or are they some artifact of the Retrospect Add Client process?"

     

    To which the Agent Response was: 
     

    "The Retrospect Client runs with full admin permissions (root of the Mac).  Retrospect asked the operating system to display all available volumes.  If extra volumes are displayed on a newly added client, it is because the file system reported the volumes exist, even if you are unable to see them yourself.  I am unable to explain exactly what those volumes are in your case, but the operating system does believe they exist in some way."

     

    To which I have now replied:

     

    "With the greatest respect, I simply don't accept the explanation in the response of July 26, 2017 12:26 [which I have copied as the Agent Response two paragraphs above this].

     
    The only way the Retrospect 'backup server' can get any information about what's on any drive attached to a client computer is through the Retrospect Client for that client computer.  That Retrospect Client is running with the same full admin permissions, under the same OS, when it is being used for a Backup as when it is being used to Add a Source.  How can the 'backup server's' Add Source see extra volumes on a newly added client, but the same 'backup server's' Backup process give 'Scanning incomplete, error -1,101 (file/directory not found)' messages for those same extra volumes?"
     
    I have added to that reply a final paragraph linking to this thread, especially posts #1 through #5—which refer to similar -1101 error problems with a Windows "backup server" and Windows clients. 

  16. I've been getting " Error -1101 (File/directory not found) " errors for years. I run Multi Server (ver. 8.5) on Windows and I use it to back up both Win and Mac computers. I get the error only with the Macs and I have to restart the retroclient on the related Mac. It's so bad that I had to create a script to restart the retroclient everyday before the backups occur. I called in the past and got nowhere.

     

    I'm reluctant to upgrade because I know the bugs are all still there. What's the point?

     

    Exact error: Can't access volume <vol> on <client>, error -1101 ( file/directory not found)

     

     

    Dan Sheehy may want to see this recent post by me, which I made to a thread in the Windows Products—Retrospect—>Professional forum even though it concerns recent -1101 errors for one of my Mac clients (I posted it there because it might have some relevance to the existing thread's discussion of -1101 errors, and because there is no equivalent thread in the Retrospect 9 or higher for Macintosh forum). 


  17. Maybe bug #6750 "Fixed Mac [my emphasis] client hooks for external scripting with event handlers", but didn't fix Windows client hooks.  If I were saskia, I would [a] make sure his/her Windows server is running the latest Retrospect Client software and—if that doesn't cause the incremental backup of the Windows server to show up in the log— submit a Support Case as per post #5 in this thread.  If is necessary, and saskia acts fast, maybe the Retrospect engineers can put the fix into Retrospect Mac 14.5/Retrospect Windows 12.5, which based on past history are due to be released in early September.


  18. This may not have anything to do with Roger Fajman's problem, since I'm a Retrospect Mac administrator.  

     

    However, in order to test out Retrospect e-mailing (which I don't normally use, because my "backup server" machine is 40 feet away from my client machines in my apartment) in connection with a script hooks problem another Retrospect Mac administrator is having, yesterday I Removed and Added one Mac client after having updated its Retrospect Client software to the latest version.  When I then ran my usual incremental "Sun.-Fri. Backup" script this morning, I got -1101 errors for three volumes other than the boot volume on the one client that is a Source for that script.  It turned out that these other Retrospect-detected volumes are some kind of garbage (cache volumes?) on my one-and-only SSD drive in that laptop client.

     

    When I looked at the Source definition for that client, it turned out that Retrospect Mac—the latest version—had defaulted to selecting All Volumes in the options dropdown for that newly-re-Added client Source.  I have now re-Removed and re-Added that Source, changed the options dropdown to Selected Volumes and selected only the boot volume for that Source, and re-checkmarked that Source for all scripts that back it up (and dragged that Source up to the top in the summary window of all multi-source Scripts that are supposed to back it up first).  We'll see whether that change makes my -1101 errors go away.

     

    P.S.: The change did make my -1101 errors go away.  Again, since all my machines are Macs, this may not have anything to do with Roger Fajman's problem.

     

    P.P.S.: I have now filed a Support Case about these -1101 errors.  We'll see if they're a result of a Retrospect bug or a macOS bug.


  19. At this point I am monitoring data passed to retroEventHandler.sh by Retrospect to understand the syntax. BUT unless I am sorely mistaken, some of the successful backups don't seem to be flagged and some of the messages seem to come at the wrong time (StartSource at the end of the backup for example, which is a bit late if your want to make a database quiet, not that I need to). I will grab more info as my usual backups come and go and then update this message.

     

    BTW, I have an existing web interface for our computer stats and I will not be using any 3rd party tools to complicate my setup.

     

    saskia should make sure he/she is monitoring data passed to one of the two RetroEventHandler.sh shell scripts contained in the latest version of the archive.  There is always the possibility that the archive was updated at least partially because of error(s) in the previous version, notwithstanding my hypothesis.

     

    Definitely some backups are not reported.

     

    saskia should make sure that he/she is running version 14.1 of Retrospect Mac for both Engine and Client, because the Release Notes for that version say "Fixed Mac client hooks for external scripting with event handlers (#6750)".  If some backups are still not reported, then I would suggest temporarily enabling e-mails as I suggested in post #2 of this thread.  If the resulting e-mails do not report all backups, and/or if the results of saskia's monitoring data passed to the RetroEventHandler.sh shell script do not match what the e-mails report, then saskia should file a Support Case per post #5 in this thread.


  20. The information Saskia wants is no longer available in the form it was available last night, because of an "anti-miracle" that occurred sometime between 7:50 p.m. yesterday evening and 9:30 a.m. this morning.  The "anti-miracle" is that the contents of the downloadable .ZIP archive I mentioned in the first paragraph of post #4 in this thread no longer contains what this Knowledge Base article says it should contain.  In particular, there is no longer a free-standing sample_sh file in the archive.

     

    That free-standing sample_sh file in last evening's version of the archive contained a Bash shell script with functions that would be called for various Retrospect Events. Most of the functions didn't have much executable code—only success and error messages, but the parameters for the various functions were understandably named and IIRC described in comments at the top of the file.  The obvious reason the functions in that file did not have much executable code is that they were not designed to feed into any monitoring system.  By contrast, the only Bash shell scripts in this morning's version of the archive are in folders named "IFTTT" and "Slack", where they are named RetroEventHandler.sh.  For understanding parameters, the file sample_c.cpp in the folder "Sources" in the folder "Sample C" may be helpful.

     

    One possibility is that I imagined reading the sample_sh file in last evening's version of the archive, but that doesn't explain why sample_sh is still listed under the "Example scripts" section in the Knowledge Base article—even though it no longer exists in the archive linked to at the top of that section.  Here follows my hypothesis, based on [a] the timing of the change in the archive and the fact that Retrospect Technical Support isn't allowed to author or change Knowledge Base articles.  My hypothesis is that Retrospect T.S. got wind within the last 24 hours of what saskia wanted to do, and decided it would cause a lot of trouble for both him/her and T.S..  So they modified the archive, but were not allowed to modify the Knowledge Base article.  They probably think saskia would be better off using IFTTT, or Slack if he/she is willing to spend the money.  Again that's purely my hypothesis.

     

    Sorry, saskia.


  21. If you think this is a documentation deficiency that should be fixed by Retrospect Inc., you will have to submit it as a Support Case.  For English speakers, that is done by going here http://www.retrospect.com/en/support/contact, and filling out the form (sorry, I don't know what the equivalent addresses are for non-English speakers, but they can figure it out from their appropriate Retrospect website address).  IMHO this is quite reasonable; obliging you to fill out the form provides Retrospect Inc. with useful details about your Retrospect installation that they would otherwise have to query you for.

     

    As a result, Retrospect Inc. will pay no attention to your post in this forum.  On 12 December 2016, in response to a letter I snail-mailed to Mayoff,  I received an e-mail through a Mayoff account that was signed by JG Heithcock, CEO, Retrospect, Inc. http://www.retrospect.com/en/about#exec.  In it he says "From reading your letter, I think the main issue is that you view the forums as a good place to talk to us, Retrospect, Inc. But we view the audience of the forums as restricted to our customers [my emphasis]. The one caveat we have made on that is for feature requests, largely as we would like to see if other customers also agree on the desirability and feature set for these requests."

     

    That means that the only audience for "Retrospect documentation requests" in this forum will be other administrators of Retrospect.  Nevertheless, by posting in this forum you are providing a useful service to us fellow administrator peasants.  Thank you.

     

    Please be aware that the "description of your issue" in the Support Case form is IME limited to about 2000 characters by the Support Case software.  If you go over that limit your "description" will be broken up into a "description" plus one or more "additional notes".  The same is true for any additional notes you may later post yourself.  I suggest that, to avoid the appearance of choppiness in your Support Case, you create your case in a post in this forum and then copy it paragraph-by-paragraph to your Support Case. 

     

    Note that, despite the new dialogs in the Retrospect Inc. Support Case system urging you to sign up for Annual Support and Maintenance, Mayoff has verbally assured me that you don't need to be signed up for ASM to request more documentation—only to get personal assistance with coping with the problem you need it for.

     

    If this post sounds formulaic, that's because I intend it to be.  I intend to link to it in every new thread that appears in this forum, unless the OP either is merely asking for help or indicates that he/she has or will open a Support Case for the documentation request that the thread reports.  Of course, Mayoff could take 5 minutes of his time to post a slightly-more-polite version of this post as a  "sticky thread" that will always appear at the top of the forum.  I don't intend to hold my breath until that happens ;).

     

     


  22. Has saskia looked at this Knowledge Base article, and downloaded the .ZIP file it links to under the "Example scripts" section?  There are a couple of Bash script examples that hook into external monitoring systems (one of which saskia may have), but the example that sounds most promising for him/her from the description is sample_sh.

     

    If that's not sufficient, IMHO saskia should file a Support Case request for documentation for the arguments.  My next post in this thread will be a boilerplate explanation of why and how to file a Support Case.  If saskia is still within the trial period of Retrospect use, he/she can also phone Retrospect Tech Support.

     

    P.S.: Although the Knowledge Base article doesn't say so, script hooks are a feature added to Retrospect Mac 14 (and Retrospect Windows 12); I presume saskia already knows that.


  23. On 7/13/2017 at 12:39 AM, x509 said:

    David, I agree that Dantz management doesn't want to expose all its bugs and bug history to the world.  But Dantz is hardly unique in that issue.  I also use an Adobe product for photographers that suffers from the same issue, andI don't know if Adobe is so militant (my word choice) about concealing the bugs.  What I do know is that any software of any degree of complexity is going to have some "technical debt," some of it quite old, if only because bugs have to be prioritized for fixing.  I also think that buyers of such software understand that issue, more than managements realize.

     

    Also, if some Dantz competitor started using the bug list as a weapon against Dantz, that would probably come across as

    (1) sleazy, very sleazy

    (2) hypocritical.

     

    x509

     

     

    The problem is that Retrospect Inc. (the modern name for Dantz Development Corp.) is in a different marketing position from Adobe.  It cannot have escaped your notice, x509, that Adobe has IMHO a near-monopoly on certain categories of software products for photographers.  (Although that near-monopoly was undoubtedly obtained mostly by a combination of product excellence and competitors' mistakes, in at least one other category of graphics software products Adobe's near-monopoly was gained by tactics that could be categorized as sleazy.)  Being in that position, Adobe [a] can afford to employ an extensive staff of skilled testers to catch bugs before release of new versions of its software and need not be afraid to admit existence of bugs after release.  Adobe also [c] can afford to employ knowledgeable employees to aggressively scan user forums to detect bugs and [d] can afford to employ enough programmers to promptly fix bugs that come to Adobe's attention.

     

    Unfortunately Retrospect Inc. is not in a near-monopoly position for backup software, and has not been that position—even for Mac backup—since at least 2007.  See  the second paragraph in the "History" section of the Wikipedia article (incidentally DovidBenAvraham's reference for the first sentence of that paragraph is a Macworld article which to this very day is linked to in the fourth-from-earliest post—made by Mayoff—in the Latest News forum on this website).  Thus IME Retrospect Inc. does not qualify in categories [a] or or [c] or [d] as described in the first paragraph of this post.  Therefore IMHO Retrospect Inc. management has "rabbit ears" about its "technical debt", some of which became years old before being brought to that management's attention.

     

    That's why I say, as my third sentence in the second paragraph of post #10 in this thread, "I think, however, that Retrospect Inc. ... doesn't want to scare off potential software purchasers".  Since making post #10 in this thread, I had a reply to a feature request Support Case from a senior Retrospect Support engineer, which I posted nearly intact in the thread related to that feature request in this Forum.  Before posting I asked the engineer if it was OK to do so, and he wrote "If you just mention it on the forums, that is fine. I'd appreciate if you refrain from bringing it up to your Wiki correspondent, as that is a much more likely place for our competition to see the information."  As I pointed out to the engineer, DovidBenAvraham is constrained by Wikipedia's requirement for a Neutral Point of View (NPOV) in articles; therefore, even if I had mentioned it to him, DovidBenAvraham would generally never include a mention of a Retrospect bug in the Wikipedia article—although DBA did make a brief parenthetical exception for the Wake-on-LAN feature for Retrospect Mac (announced in 2009, but it isn't clear whether it ever worked even in Retrospect Mac 😎 .

×