Jump to content

DavidHertzberg

Members
  • Content count

    1,241
  • Joined

  • Last visited

  • Days Won

    41

Posts posted by DavidHertzberg


  1. I think Ash7 is assuming that each Snapshot entry for a file now contains the concatenated names of each of its enclosing directories.  I doubt that's true, because it would make each Snapshot entry very lengthy, and therefore the total size of a Snapshot very large.  Instead I suspect each Snapshot entry contains the concatenated entry-numbers-within-parent-directory of each of its enclosing directories.  Ash7 should take a careful look at pages 30-31 of the Retrospect Windows 12 User's Guide, and decide what he/she thinks "A Snapshot is a list—you can think of it as a picture—of all files and folders on a volume when it is backed up" means.

     

    If I'm right, it would explain why Retrospect Inc. has not already implemented what Ash7 proposes—even as an option.  Note that the fifth paragraph of this section of the old Wikipedia article starts out "Retrospect does file-level deduplication, patented as IncrementalPLUS."  DavidBenAvraham's reference for that is page 21 of the Retrospect Mac 6 User's Guide, the oldest UG available on the Retrospect.com website.  Although Dantz Development Corp.'s patent has surely expired by now, you can't—at least you're not supposed to—get a U.S. software patent for something that is "obvious ... to a person having ordinary skill in the art to which the claimed invention pertains".  I suspect that what made IncrementalPLUS patentable is something rather tricky involving the Snapshot and Catalog File.

     

    P.S.: Expanded second paragraph with evidence that Snapshots are trickier than Ash7 may think.


  2. I think Ash7 has misunderstood the basic issue I raised in post #9 of this thread.  It is also a human factors issue, not just a feasibility issue.  Let me give you a contrived simple example:

     

    Let's say that on 29 June there were a whole bunch of existing files on computers at Ash7's installation whose names were too messy for his/her tastes.  So on 30 June he/she prefixed all the objectionable file names with "AlphaProj" and then ran a backup.  If Ash7's Retrospect feature suggestion had been implemented, these files would not be re-backed-up, only their names would be changed in the Snapshot—of which a copy would be saved in the Catalog File on disk for his Backup Set and another copy saved on the Backup Set's latest media member (see the fifth paragraph, counting the bolded one, in this section of the old Wikipedia article).  Meanwhile, let's say that on 30 June one of Ash7's users—call her Rebellia—had simultaneously renamed her own client computer copy of one of the messily-named files, prefixing its name with "CharlieCust".  Since Ash7's Retrospect feature suggestion had been implemented, that existing file would not have been re-backed-up to the same Backup Set that Ash7's installation was using daily that last week in June; only a notation of its new name on that user's machine would have been made in the Snapshot for 30 June.  

     

    Now let's say that at 1 a.m. on 1 July a water leak at Ash7's installation destroys both the external hard drive containing the Backup Set's Snapshot-containing Catalog and Rebellia's computer.  Let's say that Ash7 was running his backups directly to a Cloud Backup Set, so that the latest Backup Set member is safely offsite.  Ash7 returns to his/her installation at 9 a.m. on the morning of 1 July, and runs out to buy a replacement external hard drive for the "backup server" and a new computer for Rebellia.  Ash7 then rebuilds his Snapshot-containing Catalog File from the Cloud Backup Set, and uses it to Restore the disk on Rebellia's new computer.  Does the copy of the file on Rebellia's new computer end up with a name prefixed "CharlieCust", or does it end up with a name prefixed "AlphaProj"?

     

    BTW, based on my further reading of the section of the Wikipedia article linked-to in the second paragraph of this post, I now think that the list of Also Known As names would be specifically in the Snapshot, not just in the Catalog File.  So I've changed post #9 in this thread accordingly.


  3. ProFromGrover has made this reply to my OP in the "Product Suggestions—Windows" thread.  I would have preferred that he had made that post in this thread, since IMHO his reply has more to do with the "Windows Console" app's desirability than feasibility.  However I can see arguments both ways as to in which Forum he should have posted his reply, so I have replied to his reply there.


  4. What ProFromGrover fails to appreciate, IMHO, is that the admin tool he talks about in post #2 only works if you're running the Retrospect Virtual equivalent of the Retrospect.exe "backup server"—called the Retrospect Virtual Host Server—in some variety of virtual machine manager.  Doing it that way does an "end run" around the problem briefly described in the second sentence of the second paragraph (the one directly below the bulleted items) of this section of the old Wikipedia article, because the security features added to Windows Vista apparently don't apply to communications between a process running in a virtual machine manager and a process running on another Windows machine (virtual or hardware)—namely the Retrospect Virtual Management Console.

     

    How about all the Retrospect Windows administrators who can't afford either the expense or the time to execute this "end run"?  If Retrospect Inc. chooses to say to such administrators "Sorry, but you're not part of the future—so we won't do anything to ease the kludginess described in the 'New Windows user' thread", then so be it.  But I don't think that will help the reputation of the Retrospect software.  And how about Retrospect Mac administrators, whose installations I think typically don't run all their apps in virtual machines?  As described in the fourth paragraph of post #18 in the "New Windows user" thread, Retrospect Mac administrators don't have the kludginess faced by Retrospect Windows administrators—so why should they want to get their installations to switch to the "Retrospect admin tool of the future for all platforms"?

     

    BTW, both ProFromGrover and I may be skating on thin ice by referring to Retrospect Virtual in any way.  Almost 3 months ago I had a single-post thread deleted from both the "Windows Products—Retrospect -> Professional" and the "Retrospect 9 or higher for Macintosh" forum.  The e-mail accompanying the deletion, from support@retrospect.com, said "Posting anything about Retrospect Virtual is totally off topic from the topic in the Retrospect forum."  I think the real problem Retrospect Support had with my single-post thread was that—in its main topic of discussing something done to the Retrospect Mac 14 and Retrospect Windows 12 User's Guides (my reference to Retrospect Virtual was just a passing speculation on where the UG committee had been spending its time)—my post used a verb derived from the name of the East Germanic tribe that sacked Rome in 455 C.E., but we'd better be careful.  Therefore I will simply refer readers to this Retrospect Inc. website page, which links to documentation—as well as (higher in the web page) to the YouTube video linked to in post #2—that seems very preliminary IMHO.


  5. I'm sorry I'm late to posting in this thread, but I just thought of a problem with Ash7's proposal.  What if he/she has done the "renaming of a bunch of large files" that he/she reports in the third paragraph of post #1 in this thread, and then has something bad happen to the drive(s) on which those files are currently stored?  When he/she then Restores those files, are they restored with their current names, or with their original names?  If the files are Restored with their original names, then the administrator would lose the benefit of having "reorganize[d] a large library of files with new names" (fourth paragraph of post #1).  If the files are to be Restored with their current names, then Retrospect would have to have updated the Snapshot with the new names, and substitute those new names when Restoring.

     

    But if the latter, what if another user saved the same files under different names, has to Restore them, but wants the Restored files to have the names that particular user gave them?  It seems to me the Snapshot would therefore have to have for each file a list of Also Known As names, each paired with the drive on which the particular Also Known As name is used.  That would be a significant change to Retrospect, which would make its Snapshots look like the files U. S. police departments have to maintain (I have never worked for a police department, but I've watched enough crime dramas to  know what "AKA" stands for).  In the U. S. it is AFAIK not illegal for a person to use more than one name (I used to be married to a woman who kept her previous married name for professional use, and also uses a made-up name for her artistic career), although AFAIK a person must use a single name for governmental records.  Please, Ash7, don't make Retrospect go there!

     

    P.S.: Replaced Catalog File with Snapshot, because I think the list of Also Known As names would have to be placed specifically there.


  6. I've now followed a version of my suggestion in post #24 of this thread, but in a different direction.  Here's my Feature Request to create a separate Windows user-space GUI app similar to the Console app in Retrospect Mac, which is now a Support Case.  It assumes such an app would have to run on a different Windows machine from the "backup server" Engine—as is allowed for Server editions of Retrospect Mac.

     

    I realize this will be a controversial Feature Request.  First of all, the proposed "Windows Console" app would only be feasible to implement if two things are true: [1] By December 2006—inferring from the Ashlee Vance article—the EMC Insignia engineers had made significant progress in developing a Windows, as well as a Mac, version of the separate Console app.  [2] The source code for that Windows version has not been lost, and the Retrospect Inc. engineers can find it.

     

    Second, the proposed "Windows Console" app would only be worth implementing if a significant percentage of Retrospect Windows administrators of Server editions would be willing to use it.   And they'd probably have to put up with the app's "polished interface" being based on the Console GUI that was adopted for Retrospect Mac 8 in early 2009, as summarized in the third bulleted item and its sub-items after the first paragraph here, because that's the GUI the EMC Insignia engineers would have been trying to implement in December 2006—even though the "Windows Console" app would probably be changed to use the Retrospect Windows terminology.  This is a question that definitely should be discussed, and I think the proper place for discussion is in further posts to the "Product Suggestions—Windows" thread I've linked to in the second sentence of the first paragraph of this post.

     

    OTOH, whether a significant percentage of Retrospect Windows administrators of Server editions would be willing to use the proposed "Windows Console" app would also depend on whether they would be willing to allow the Retrospect.exe "backup server" app to run continuously.  That is what Retrospect Mac users do with the Retrospect Engine app, as mentioned in the fourth paragraph of post #18 in this thread.  If you don't run Retrospect.exe continuously, the proposed "Windows Console" app probably wouldn't do much for you beyond what occasionally running the Retrospect Dashboard can do for you now.  I think that particular discussion belongs in this thread, because it is basically an extension of iCompute's original question.

     

    P.S.: Added fourth paragraph; also added mention of changing the proposed "Windows Console" app's terminology to the second sentence of the third paragraph.


  7. This suggestion is an offshoot of this thread in "Windows Products—Retrospect->Professional", which I shall henceforth refer to as the "New Windows user" thread.  It is motivated by iCompute's astounding revelation in post #21 (posts beginning with #21 are on page 2 of the "New Windows user" thread) : "I have a Mac laptop, with a copy of the Mac Retro 'console' on it. Just 'cuz, I fired up the console, and lo and behold, it *works* on the WINDOWS Retro server. As far as I can tell, I get the full function of the Mac engine/console via the Mac console when operating/controlling the Windows Retro server."  

     

    In the fourth paragraph of post #22 in the "New Windows user" thread, I belatedly realized that we shouldn't consider iCompute's revelation quite so astounding, because what is now known as the Retrospect for iOS app has been working—connected to a Retrospect Windows "backup server" as well as a Retrospect Mac "backup server"—since 2010.  This means that the "engine side" of Retrospect.exe retains the capability of exchanging messages with another app—even if that app is not the Retrospect Launcher.  In post #23, after doing some inferences based on an 18 January 2007 article in The Register by Ashlee Vance, I concluded "My guess is that the Retrospect engineers simply left the code for interprocess communication in Retrospect Windows 7.5 and following, where it has remained ever since—ready for iCompute to activate its inter-machine capability with a Retrospect Mac Console."  So creating a separate Windows user-space GUI app similar to the Console app in Retrospect Mac seems feasible, so long as the GUI app is run on a different Windows machine from the "backup server" Engine—as is allowed for Server editions of Retrospect Mac.

     

    What makes this suggested app desirable is the discussion on page 1 of the "New Windows user" thread.  iCompute, an experienced Retrospect Mac administrator faced with his first Retrospect Windows installation, was especially flummoxed by the fact that the Retrospect.exe app stops any running scripts cold if he logs off—unlike the Retrospect Mac Engine app if you quit the Console app.  Guided by ProFromGrover, he discovered that the Retrospect Dashboard.exe app is a way to work around this problem, which I had explained in post #2 is a consequence—along with the need for the Retrospect Launcher Windows service—of security features added to Windows Vista and beyond.

     

    What makes this suggested app seem practicable with a reasonable amount of Retrospect Inc. engineering effort is a further inference from the Ashlee Vance article, stemming from the fourth paragraph of post #23 in the "New Windows user" thread.  It is that by December 2006 the EMC Insignia engineers had made significant progress in developing a Windows, as well as a Mac, version of the separate Console app.  If this inference is correct, and the source code for that Windows Console was saved, it should be possible to update that source code with the fixes that were made to the Retrospect Mac Console in later point releases of Retrospect Mac 8 and later versions of Retrospect Mac.  There is a caveat: the resulting Retrospect Windows Console app would, barring extensive modifications, use the Retrospect Mac Console GUI—although it would be fairly easy to change the terminology within the GUI back to the terminology of Retrospect Windows.

     

    What makes this suggested app seem more desirable is that, based on what other administrators have posted on page 1 of the "New Windows user" thread, the combination of the old Retrospect GUI and the limitations imposed with Windows Vista makes using Retrospect Windows a kludge-filled mess compared to using Retrospect Mac.  That's clearly why iCompute wrote at the end of post #21 "Way back when I posted this thread, I had no idea this would work. Turns out that it does. I hope it's supported. ;->"  I think that, after reading 1.3 screen pages in the third bulleted item in this section of the old Wikipedia article, administrators running a Server edition of Retrospect Windows will use the proposed Retrospect Windows Console app—and bless Retrospect Inc. engineers for developing it.


  8. Please flag any spam posts as spam. Forum administrators will be notified immediately when a post has been flagged.

     

     

    Sorry, Mayoff, I didn't know how to "flag" posts as spam; that's why I filed a Support Case to get rid of kapedDus's spam post.  You might consider posting instructions on how to "flag" posts where Forums users are likely to find them.

     

    This post is disposable once Mayoff has read it, so I will now experiment by "flagging" it—presumably by using the Report button.


  9. It looks as if—according to this thread—you might be able "to boot a client from the Retrospect DR CD, connect the USB media and recover that client directly instead of having to set it up and run a recovery job from the server."  However post #2 in that thread says Johnny Mac was able to do so because the same USB disk that held his latest Retrospect backup for that client also held the catalog for the Backup Set.  iCompute might not want to put his catalog on a USB drive that is also a member of the same Media Set; I wouldn't.

     

    I presume Johnny Mac did a user-initiated Restore.


  10. Why not file a  Feature Request that the Retrospect Mac Console—when connected to a Retrospect Windows "backup server"—allow access to the few  "things in the Retro Windows application that do not exist on the Mac" that iCompute refers to in post #21?

     

    However IMHO that Feature Request would likely run into a corporate political problem.  If my explanation in post #23 is correct, Retrospect Inc. has known since at least 2010 that a Retrospect Mac Console can be used to control the Engine in a Retrospect Windows "backup server".  But the closest they have come to admitting that fact is by releasing the "Retrospect for iOS" app in 2010, as I pointed out in the fourth paragraph of post #22.  I think one reason for Retrospect Inc.'s reticence is that, to avoid embarrassing Microsoft, they don't want to call attention to the fact that a Mac app can access a Windows user process in a way that Windows security restrictions prevent another Windows user process from doing.  I think another reason is that, considering the longtime Windows vs. Mac user dispute that JamesOakley alludes to in this post, Retrospect Inc. marketing may not consider the limited number of administrators who would do what iCompute is considering doing worth the kerfuffle.


  11. After reading the rest of chapter 9, which starts on page 329 of the Retrospect Windows 14 UG, I partially withdraw what I said in the third paragraph of post #3 in this thread.  The "Using the Retrospect Emergency Recovery Disc" section, which starts on page 332, seems to lead a user through the necessary steps—including partitioning and formatting the new hard drive before Restoring—under the control of the Emergency Recovery wizard.  That is assuming the user can attach the new hard drive locally to the "backup server", but that would require the new hard drive to be an external one in its own enclosure.  If the new hard drive is installed internally in its computer (which was presumably a Retrospect client before it crashed), then the user will have to follow the "Restoring as a client" sub-section starting on page 339—which I assume means the partitioning and formatting was already done by whoever installed the new hard drive.  However both of these alternatives eventually require doing a Restore per UG Chapter 4 "Immediate Operations", which would seem to require the user be at least assisted by a Retrospect administrator.

     

    So I accept that creating an Emergency Recovery Disc might be a worthwhile thing for iCompute to do.  As he said in post #1 in this thread, he could do this by downloading a trial version of Retrospect Windows just for this purpose.  

     

    However iCompute might want to think big, by filing a Support Case with a Feature Request for adding the capability of creating an Emergency Recovery Disc for Windows computers to Retrospect Mac.  Unfortunately it would be a bit difficult for the Retrospect Inc. engineers to comply with this Feature Request.  Step 2 on page 330 of the UG says "Click Next.  You will then be asked for the Windows ADK software. Retrospect uses the ADK to create an Emergency Recovery Disc." The Windows Assessment and Deployment Kit is "a collection of tools and technologies produced by Microsoft designed to help deploy Microsoft Windows operating system images to target computers".  There might be Mac-compatible software equivalent to the Windows ADK sufficient to install Windows PE on a CD or thumb drive.  Alternatively, the Retrospect Inc. engineers might manage to offload creating an Emergency Recovery Disc for Windows computers to a Windows client machine, since there must exist one of those in order for the feature to make any sense for the installation.  But either of these alternative seems like a lot of effort for the engineers, which is undoubtedly why the feature doesn't already exist in the Retrospect Mac "backup server" Engine or Console.

     

    P.S.: Transferred last sentence in second paragraph, and all of third paragraph, to iCompute's other thread.

     

    P.P.S.: Split off remaining last sentence of second paragraph into new third paragraph; expanded that to explain why it would be a lot of effort for the Retrospect Inc. engineers to implement the new Feature Request. 


  12. After looking at the User's Guides for the latest versions of Retrospect Windows and Retrospect Mac, as far as I can see the only advantage to having an Emergency Recovery Disk for a Windows client machine is that it gives the user a CD from which to initially boot the crashed client.  However after booting from that CD, page 332 of the Retrospect Windows 12 UG says, "Once a Windows computer has been booted from the Retrospect Emergency Recovery Disc, its hard disk drives can be partitioned and formatted, and it can be restored either locally, by using the Retrospect application with connected storage media containing the backup, or from a Retrospect server on the network via the Retrospect Client software."  So the user has to know how to partition and format a hard drive attached to the machine, and then Restore it using the Retrospect "backup server".

     

    On the other hand, pages 156-157 of the Retrospect Mac 14 UG starts out, "1. Install new Windows system software on the newly-formatted hard disk. Restart from this volume.  2. Use the Setup program to install the Retrospect client software as described in “Installing Retrospect Client software on a machine running Microsoft Windows” in Chapter 1."  This is followed by steps 3. through 10., which essentially spell out how to Restore the hard drive using the Retrospect "backup server".

     

    So either way the user needs to be provided with a hard drive.  If he/she is also provided with a Retrospect Emergency Recovery Disc, that hard drive can start out erased, but then after booting from the CD the user must partition and format the hard drive before Restoring the entire contents of the hard drive—including Windows files—using Retrospect.  If he/she is not provided with a Retrospect Emergency Recovery Disc, that hard drive must start out partitioned and formatted with Windows system software installed.  Frankly, it seems to me to be a tradeoff between how much Windows utility work the user has to know how to do vs. how much hard disk prep the administrator must have done in advance.  Take your pick, iCompute.

     

    BTW, page 329 of the Retrospect Windows 12 UG mentions a second—slower—method of restoring a computer that won't boot.  "Install a Windows operating system and the Retrospect application or Retrospect Client software, and then perform a complete restore as outlined in 'Restoring from a Full Backup' on page 207 of the Retrospect User’s Guide."  But iCompute won't find that sub-section on page 207 of the Retrospect Windows 12 UG—or anywhere else in that UG, nor will he find it on page 207 of the Retrospect Windows 8 UG—or anywhere else in that UG.  In fact he'll have to go back to page 207 of the Retrospect Windows 7.5 UG, which starts out with several steps to try before reformatting the hard disk and installing Windows.  Ah, proofreading of UG revisions, it's wonderful (insert appropriate smiley here)!


  13. I've had further thoughts this afternoon about what I wrote in the first two paragraphs of post #22 directly above this post, and I now have an alternative explanation for why iCompute is able to control a Retrospect Windows Retrospect.exe Engine from a Retrospect Mac Console.  This explanation does not assume any message-passing security hole within Retrospect.exe, but instead assumes that inter-machine message passing code was put into Retrospect Windows 7.5 and left there.

     

    The explanation relies on a careful reading of this 18 January 2007 article in The Register by Ashlee Vance.  DovidBenAvraham found it less than a week ago, and updated the lead and "Retrospect Windows 7" sections of the old "Retrospect (software)" Wikipedia article accordingly.  Vance's article was written two weeks before Windows Vista was released worldwide; it deals with EMC's killing of plans to release Retrospect 8 following a mass layoff at EMC Insignia's Walnut Creek CA offices.

     

    The seventh paragraph of the article says "Our sources indicate that a skeleton crew has been left to oversee the release of a point upgrade to Version 7.5 of the software. That code due out this quarter will include updates for Microsoft's Vista and Apple's Leopard operating systems."  Note that that paragraph does not refer to just a Retrospect Windows 7.5 release, but also implies an apparent Retrospect Mac 7.5 release.  IMHO this means that the EMC Insignia engineers had already made substantial progress in merging the Windows and Mac Retrospect code bases.

     

    But what were the engineers working towards?  Starting with the fourth paragraph from the bottom of the article, Vance says "'The engineers were halfway through 8.0 in December and then all work ceased,' one source said."  Vance follows that with "'From what I understand, the new version will not even be released,' said another source. 'Everyone had such high hopes for the product. It had a polished interface, and I think it would have been a success.'"  Note that these paragraphs do not refer to just a Retrospect Mac 8.0 release, but also imply an apparent Retrospect Windows 8.0 release.  IMHO this means that both flavors of Retrospect 8.0 were intended to have the new interface that eventually was released in early 2009 for Retrospect Mac 8.0.

     

    That new interface separated the Engine and Console into separate processes, communicating with each other on the same machine—or between machines if a Server edition of Retrospect was being run.  But Microsoft essentially torpedoed the possibility of same-Windows-machine interprocess communication sufficient for the EMC Insignia engineers' Retrospect plans, when it released Windows Vista on 30 January 2007.  So the rehired EMC Iomega engineers hurriedly released Retrospect Mac 8.0 in early 2009, a release which was roundly panned for both its bugs and the new interface—which was confusing to many Retrospect Mac administrators.

     

    My guess is that the remaining EMC Insignia engineers simply left the code for interprocess communication in Retrospect Windows 7.5 and following, where it has remained ever since—ready for iCompute to activate its inter-machine capability with a Retrospect Mac Console.

     

    And here's a quote from a very knowledgeable inside source, namely Mayoff.  "Retrospect 8 for Macintosh is totally different from version 6.x and earlier for Macintosh. Retrospect 7.7 for windows and version 8 for windows share probably 99% of the same code."  That doesn't exactly prove my guess is correct, but it indicates that the non-interface code added for Retrospect Mac 8 and 9 and 10 was merged into the code for 2013 Retrospect Windows 8, rather than the reverse.  I'm a retired programmer, and programmers hate to delete code that used to work.


  14. Holy s**t, iCompute, and congratulations!  I presume the copy of the Console app on your Mac laptop has a Server license, so that it can control the Engine of a "backup server" on another machine.

     

    I have no training in inter-process communications, and the only experience I have in Windows programming was from 1999 to 2004 using Borland C++ Builder—which is a version of Borland Delphi that uses an enhanced C++ instead of an enhanced Pascal as the programming language—to create single-process applications.  However IMHO (very HO) this means that the Retrospect.exe Windows app must have the ability to exchange inter-process messages with another process that has the proper authorization.  According to my ignorant reading of the third paragraph in this section of the Wikipedia article "Security and safety features new to Windows Vista", another user mode application should not have such an authorization within Windows.  However it looks like a Macintosh application can be made to appear to a Windows user mode application to have such an authorization.

     

    This makes sense in the light of the second paragraph (the one after the bulleted items) of this section of the old Wikipedia article "Retrospect (software)".  Since the Retrospect Launcher is a Windows service process, it must have the proper exalted authorization to pass messages to and receive messages from the Retrospect.exe user-space process—which contains the equivalent of the Retrospect Mac Engine and Console code.  Maybe, just to avoid a bunch of re-programming and to keep as much commonality as possible with the Retrospect Mac code, the "console side" and the "engine side" of the Retrospect.exe app also communicate with each other by passing messages—even though the two "sides" are part of the same process.  If so, it's not too much of a stretch to think that the "engine side" of Retrospect.exe retains the capability of exchanging such messages with another app—even if that app is not the Retrospect Launcher.

     

    The interesting question is whether this capability is just an unintended leftover, or whether the Retrospect Inc. engineers intentionally left this capability in—or even took extra programming steps to preserve it.  If it's the former, then this might be considered a security hole.  If it's the latter, then this must be an unadvertised feature of Retrospect Windows.  Wait a second, it's not so unadvertised; how else can the "[view-only] Console for iPhone", mentioned in the last bulleted item here and now described  in the Retrospect for iOS appendix on page 578 of the Retrospect Windows 12 User's Guide, work for Retrospect Windows?  That iOS app was developed by a Retrospect engineer, working on his/her own time, just about the time Retrospect Inc. was spun off from Roxio in 2010.  So Retrospect Support must know about the capability.

     

    BTW,  iCompute, IMHO you should be careful about accessing the Retrospect.exe Windows app from the Retrospect Mac console.  Hofstede said in this 2016 post that the Retrospect for iOS app "can cause your Retrospect server to crash while you access it from the app in some circumstances."  That may just be a problem with the iOS app, which has not been updated since 2014, but it may indicate a problem that could affect your use of a Retrospect Mac console to access Retrospect.exe on Windows.

     

    P.S.: Revised fourth paragraph; I didn't remember Retrospect for iOS until later this morning.


  15. Yes, I did post to the wrong forum, sorry about that. Can this thread be moved?

     

     

    Sorry, jweisbin, AFAIK there's only one person with the ability to move a thread in these Forums—and that person is Mayoff.  For reasons described in the first paragraph of this post, I don't think he'll notice your request in this forum.  

     

    You could try posting that request in the "Product Suggestions—Windows" forum.  Going beyond that, you could actually click this link and create a Support Case with the "please select issue" dropdown set to Forum Request; if you include the URL for this thread in "Please enter a description of your issue", Mayoff might read that Support Case and move your thread.

     

    As of the time I post this 53 people have read the thread I posted 9 days ago on your behalf in the "Retrospect 9 or higher for Macintosh" forum.  If by now you haven't gotten any replies from other people in this thread, IMHO it's because probably nobody else has any useful suggestions to make.  Sorry about that.

     

    Please post back to let us know if you've solved your -505 problem.

     

    P.S.: Heavens to Betsy, Retrospect Inc. seems to have now eliminated the newish Support Case page sub-section that implied that you have to sign up for ASM to open a Support Case!  I guess either all the customers learned to ignore that sub-section, or Retrospect Inc. realized that the sub-section was inhibiting customers from filing Support Cases for genuine bugs—which IMHO would not be good for improving Retrospect's dubious reputation for reliability.


  16. But something like the Drupal issue queues or the GitHub issue tracker could do the same as the support case system, whilst also allowing other users to search / chip in on related cases as well as track progress towards solutions etc. (I know that Retrospect is not open source, but you can still have a similar kind of public bug tracker with closed-source commercial software)>

     

     

    IMHO, JamesOakley, you're correct on this procedural issue but fail to appreciate the associated marketing issue—at least for Retrospect Inc..  Without knowing much about issue queues/trackers (I did just now take a brief look at some documentation for the Drupal issue queues), it seems to me that having such a  queue/tracker means that all users can be aware of all the bugs for a particular system.  With the Support Case software Retrospect Inc. uses, OTOH, a user who has submitted a Support Case can only see the "description of your issue" and "additional notes" on that particular case (Retrospect Inc.'s system automatically sends an e-mail to the the original submitter containing a URL for accessing that Support Case).

     

    The marketing issue is that IMHO Retrospect Inc. doesn't want people outside the company to be able to see all the outstanding bugs that exist for Retrospect. JG Heithcock would no doubt say that Retrospect Inc. doesn't want to provide ammunition to its software competitors.  I think, however, that Retrospect Inc. also doesn't want to scare off potential software purchasers.  The "rather bad reputation" among many former users of Retrospect Mac 8, which I alluded to in the last paragraph of post #8 in this thread, is IME a gross understatement.  IMHO that has given employees of Retrospect Inc., many of whom have been with the company since it was Dantz Development Corp., what could be called a permanent case of "rabbit ears" (since there are some indications in his posts that JamesOakley is British, I should explain that "rabbit ears" is old baseball slang for a player who allows himself/herself to be bothered by shouted gibes from the opposing team or from fans in the stands).

     

    About 15 months ago I purchased a KVM switch from the U.S. subsidiary of ATEN International, which is a very reputable Taiwanese manufacturer of connectivity and access management hardware founded in 1979—5 years before Dantz Development.  I discovered a bug in the KVM switch, so I submitted an eSupport Case to ATEN.  The ATEN-website software I used to do this is evidently a version of exactly the same Support Case software that Retrospect Inc. uses.  The bug eventually turned out to be a "conceptual bug" in that model that ATEN refused to fix via a microprogramming enhancement, because in their view to do so would be a violation of the DisplayPort standard.  The "conceptual bug" affected at least two other users of that same model of KVM switch, one of whom returned the KVM switch for a refund.  I'll bet ATEN is very glad that news of that bug was not disseminated to potential purchasers of the KVM switch model by their eSupport Case system, and I'm sure Retrospect Inc. marketing management feels exactly the same way about news of existing Retrospect bugs—some of which are multiple years old because finding their causes and fixing them is complicated.

    • Like 1

  17. Your memory has not let you down, JamesOakleyRobin Mayoff is still—as he has been for years—the Retrospect Technical Support Manager.  What's different is that Mayoff (his handle on the Forums) IMHO no longer has time to even look at the Forums—much less to occasionally post a short suggestion.  That seems to be because his former assistant Alan is no longer working at Retrospect Inc., so that Robin is evidently handling all the T. S. phonecalls himself (I know that because whenever I phone  T.S., which I do as little as possible—and always only to ask a quick question of general Forums interest—because I don't have ASM, it is Robin—whose voice I recognize—who answers).

     

    I've more or less tried to fill some of the gap, although I am a retiree volunteer who has never worked for Retrospect Inc. or any of the predecessor corporate owners of the software.  I only have two years of modern experience as a Retrospect administrator (whereas Mayoff has been a full-time T.S. employee of Dantz/EMC/Roxio/Retrospect Inc. since 1994), and the atypical setup of my installation means that I haven't run into many of the problems other Retrospect administrators have.  Therefore I can't provide the answers Lennart Thelander or Scillonian or twickland or ProFromGrover or JoTraGo—among others—can.  That's why I've been aggressively encouraging posters to look for past posts containing their particular error messages, by using the Forums' Advanced Search capability.

     

    JG Heithcock's statement, which I quote in the second paragraph of post #6 in this thread, is another reason why I have also been aggressively encouraging posters to submit Support Cases for bugs or feature requests.  Because of my experience with filing a Support Case for several interlocking  -530 errors, I know that there is at least one other person "working in the back room" for Retrospect T.S..   IMHO JamesOakley is correct in thinking that it's a shame that Retrospect Inc. staff no longer look at the Forums.  I have to admit that the Support Case system makes more efficient use of Retrospect Inc. staff time, tending to eliminate the need for staff to look at Forums posts containing insufficient information.  However I do worry that Retrospect Inc. is in danger of recreating the situation described in the last two sentences in the third paragraph of the lead of the old Wikipedia article.  That situation, as I learned over the last two years from discussing my use of Retrospect in the Ars Technica Macintoshian Achaia forum, gave the Retrospect software a rather bad reputation that has endured despite Retrospect Inc.'s subsequent bug-fixing efforts.


  18. 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 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).

    • Like 1

  19. ....

     

    I'm hoping that one of the Retrospect devs will see this and have some thoughts, or that other users who have upgraded may have experienced (and maybe even circumvented) the same issue.

     

     

    None of the Retrospect developers will see this, for reasons explained in the second paragraph of my next post in this thread.  That post will be my boilerplate explanation of why and how to submit a Retrospect Support Case for this issue.  As explained in the fifth paragraph of that next post, JamesOakley can do this even though he isn't signed up for Annual Support and Maintenance—I don't have ASM but one bug for which I submitted a Support Case has been escalated to Engineering.  

     

    If the event log of his computer doesn't indicate a hardware issue, and he doesn't get a solution from some other Retrospect Windows administrator within the next day or two, I strongly urge JamesOakley to submit that Support Case, with a "description of your issue" copied from his Original Post in this thread.


  20. I'm a Retrospect Mac administrator, so I can't offer much specific help.

     

    However this post by JoTraGo sounds like it's a good method for JamesOakley to start diagnosing his problem.  I found the thread using the Advanced Search facility by clicking the gear icon on the extreme right of the top line in the Forums page that says "IPS Community" on the left.  I then typed "-1001"—including the quotes—into the Find Words box, and selected "Windows Products—Retrospect" from the Find in Forums dropdown.

     

    In the next post in that thread, LRSFC_DanJ said he found his problem was "most likely being an issue with the hard drive the catalogue file was being written to".  However that may not apply to JamesOakley's problem.


  21. I currently have Retrospect 11.5 Desktop (formerly Professional).  I use it to back up three (currently) PCs to four backup sets, each on a 3 TB hard disk, using one of the backup sets each day.  The network is a dedicated gigabit Ethernet switch.  What's the value to me of upgrading to Version 12?  The new features don't seem really applicable to me.  There are quite a few bug fixes, but I don't see why I should have to pay for an upgrade just to get fixes.

     

    The main problem that I have is frequent occurrences of backups bombing with thousands of "-1101 File or Folder Not Found" errors:

     

    ...

            [*] stfiDoBackupOne: error -1101 (file/directory not found) on C:\Windows\WinSxS\x86_wwf-system.workflow.runtime_31bf3856ad364e35_10.0.14393.0_none_3670ad90fe5c2d0f\.

            [*] and 34,579 others

            [*] stfiWaitForBackupDone: operation terminated, error -1101 (file/directory not found)

            Trouble reading files, error -1101 (file/directory not found)

            3/24/2017 6:27:38 AM: Trouble copying folders, error -1101 (file/directory not found) ddex=50,848

     

    It occurs both on the "server" and the clients, with no obvious pattern.  Usually rerunning the backup works, but that is a pain and makes Retrospect less than fully automated.  I don't see a fix for this in the list of Version 12 fixes.

     

     

    I hate to offer a solution that involves Roger Fajman or HawkinOz or anyone else spending money for an upgrade (insert appropriate smiley here), but I just noticed two fixes for the -1101 error  in Retrospect Windows 12.1 (and Retrospect Mac 14.1).  Search for "-1101" (omit the quotes) using the web browser of your choice in these release notes.  The fix to the Engine may be too specialized to apply to Roger Fajman or HawkinOz, but the fix to the Client seems more broadly applicable.

     

    I just phoned Werner at Retrospect Sales, and he confirmed that the 45-day free trial applies to upgrades as well as new Retrospect users.  He suggests that you save your old config files, just in case you need to go back to the pre-upgrade version.

     

    BTW, I agree with you folks about the cost of ASM for the Desktop product.  I don't have it, since Retrospect Support did not on the whole provide particularly useful advice during my 30-day free-advice period after I upgraded (at full new-user price) from Retrospect Mac 6.1 to Retrospect Mac 12.0.  I skipped Retrospect Mac 13 entirely, since my slow Internet upload speed means I couldn't use cloud backup and the bug fixes didn't apply to me.  However I have upgraded to Retrospect Mac 14 (without ASM), primarily out of gratitude because Retrospect Support was quite cooperative—including providing a trial of an advanced version of Retrospect Mac 13.5 that didn't solve my problem—when I reported my -530 problem as a reproducible bug.

     

    P.S.: Johnny Mac reports that at least one of the fixes in Retrospect Windows 12.1 works for him; at least I think that's what he's saying.


  22. khudson should definitely look at the "–625 (not enough memory)" section on page 526 of the Retrospect Windows 11 User's Guide.  Since the Forum he/she has posted in implies that he/she is running a Server version of Retrospect, I would definitely recommend reducing the number of execution units as suggested in the last paragraph of that section—even if he/she is actually running in only 1 execution unit.

     

    Being a Retrospect Mac administrator, I'm a bit out of my depth on some of the issues here.  However I've also gained a certain amount of experience using Advanced Search for these Forums, which is accessed by clicking the gear icon at the extreme right of the same top line that says "IPS Community" on the left.  To find posts mentioning the -625 error, type "-625" including the quotes (apostrophes also work) in the Find Words box.  To find posts discussing any version of Retrospect Windows, select "Windows Products—Retrospect" in the Find in Forum dropdown.

     

    This thread may be of interest, especially post #5 by Mayoff.  The last paragraph of that post says "Retrospect is a 32 bit program, so it can't use more then 2 GB of physical RAM.", which seems a bit obsolete in 2017.   However, because I don't know if a 32-bit version of Retrospect Windows is automatically installed on a "backup server" running on a 32-bit machine with a 32-bit version of Windows, I also did an Advanced Search on "32-bit" (including the quotes).  This thread may be of interest.

     

    khudson should also look at this Knowledge Base article.  Although that article was last updated in March 2015, the second paragraph under "Further Tips" may still be applicable if he/she does in fact have a 32-bit version of the Retrospect "backup server" installed.  But the first and third paragraphs may also be helpful.

     

    In any case, the World Computer Manufacturers Association is highly in favor of khudson buying a new server (insert appropriate smiley here).


  23. toshy, this is a little late, but I just found this post while trying to solve someone else's problem in another thread.  Although the thread linked to is about someone's -519 errors (which would probably be changed to -530 errors by the #6080 fix in Retrospect Mac 13), the post stimulated my little gray cells—because it suggested a possible cause for your problem with getting a -530 error on only some of the disks on a client.  Try unchecking the "Put hard drives to sleep when possible" checkbox in System Preferences->Energy Saver on your problematic client.

×