OH NO! HELPPPP

[pauland]

It's inexcusable that a crash-during-save corrupts the one-and-only saved file anyway, as there's a simple technique as old as the hills for avoiding that particular problem.

LOL, yes, it's called the user saving backup copies "just in case". Most software only works with the current version of a file and virtually all software has bugs of one form or another. We all have to work with what we have rather than what we would like or it should be.

Ultimately, all software backup measures are defeated by a malicious virus or death of a hard disc if a copy is not saved on seperate media.

[willdean]

LOL, yes, it's called the user saving backup copies "just in case". Most software only works with the current version of a file and virtually all software has bugs of one form or another. We all have to work with what we have rather than what we would like or it should be.

That's a depressingly passive approach! We can always ask Xara to make things better, especially when it's a simple change.

The safe way for apps to overwrite their data files is to write to a new temporary file next to the original. Once the app believes that it's written the file OK, then it replaces the original with the new one. That's the way apps like Word work - even if you think they're "only working with the current version of a file", they're still doing it in a much safer way than Xara. Windows (since W2K) even has a function specifically for this purpose, because it's such a common and useful thing to do.

[pauland]

It's not the writing of the file that's the problem as such, it's the internal data that's (I guess) corrupted in some way so that when the Xara software tries to save, it creates a fault that you see. It's unlikely that it has anything to do with the operating or file system being unable to write data away.

[PhilM]

The safe way for apps to overwrite their data files is to write to a new temporary file next to the original. Once the app believes that it's written the file OK, then it replaces the original with the new one.

That is, of course, exactly what Xtreme/Designer does. But even that method has a failure mode when the save appears to have worked OK but actually has not. Then the corrupted temporary file still overwrites the original. Remember that most people reporting file corruption only notice that something has gone wrong some time after the save operation that caused the problem.

Phil

[willdean]

That is, of course, exactly what Xtreme/Designer does. But even that method has a failure mode when the save appears to have worked OK but actually has not. Then the corrupted temporary file still overwrites the original. Remember that most people reporting file corruption only notice that something has gone wrong some time after the save operation that caused the problem.

OK, sorry, I stand corrected - I have taken the mistaken impression from some of these sort of posts that the crash occurs during the save.

Before I wrote my original post, I did watch XD6 do a whole stream of 1K writes to the original file during a save, and I did check that it doesn't appear to use ReplaceFile. It looks more that you actually take a backup copy (or a move) of the original to the temp directory, create a new 'original', and then delete the backup when the overwrite's finished. I guess you have some mechanism for automatically getting back to that backup file if things go (detectably) wrong. I am not disassembling Xara code, don't worry.

At least the new auto-backup stuff should make all this moot in future.