Jump to content

Fix for Asian Character Problem?


Recommended Posts

  • 1 month later...

 

"Still working on these issues?" Dantz has known about the Unicode problem since April 2002, if not earlier. It's hard to believe that it still isn't fixed.

 

I've been using Retrospect Express for 5 or 6 years and have been happy, for the most part. However, this bug is a deal-killer. I have waited patiently for a fix. Instead, Dantz has eliminated Express and left the bug unfixed. You expect me to pay $129 to update to a version that doesn't fix such a fundamental bug? No thanks. I think the time has come to switch to another program.

 

 

 

 

Link to comment
Share on other sites

Quote:

"Still working on these issues?" Dantz has known about the Unicode problem since April 2002, if not earlier. It's hard to believe that it still isn't fixed.

 


 

Lack of Unicode support isn't a bug; lack of Unicode support is a missing feature.

 

Fixing a bug means addressing some portion of existing code.

 

Adding Unicode support would mean a major rewrite of the program itself.

 

I'm not saying that it's not a deal-breaker for some (or for many). And I'm not saying that it doesn't suck that some files can't be backed up. But it's not as if it is some trivial fix.

 

Dave

Link to comment
Share on other sites

Hi

 

For the record:

 

Even if Retrospect had unicode support there are still some characters that may not be backed up properly. There a bunch of encoding schemes out there and OS devellopers like to mix and match. In any case, Retrospect can currently backup all but 8 Japanese characters that I am aware of. There may be some others in other languages of course.

 

Nate

Link to comment
Share on other sites

Quote:

 

Lack of Unicode support isn't a bug; lack of Unicode support is a missing feature.

 

Fixing a bug means addressing some portion of existing code.

 

Adding Unicode support would mean a major rewrite of the program itself.

 

 

 


 

Whether a bug or a lack of a feature, either way, it's a shortcoming.

 

From old posts on the subject, the problem is that Dantz is trying to cram Unicode characters into C/Pascal strings for backwards compatibility. Why waste time on backwards compatibility? Change the data format to Unicode strings.

 

When restoring backup sets, Retrospect would detect whether the members are written in the old format or the new format and adjust accordingly. For reading, the program would be fully backwards compatible.

 

When writing to existing backup sets that were already created in the old format, the same thing would happen: Retrospect would detect that the existing members are in the old format, and continue to write to that backup set in the old format.

 

When creating new backup sets, the new Unicode format would be used by default, which would be fine for the overwhelming majority of users, as most people would be restoring with the same version of the program with which they backed up: if they wrote the new format in the first place, they have the capability to read the new format. If, for some reason, someone needs to write in the old format, give them an option in the preferences panel, which warns them that if they use the old format, Unicode characters may not get backed up.

 

I haven't been inside your code, but the programming solution seems obvious.

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...