No, I'm not referring to leaders of government or major corporations...
But, in the land of FileMaker, developers struggle with the issue of files getting corrupt. Once this occurs (say after an unplanned system crash...), you really need to revert back to a golden/virgin copy of your app. else bad things can happen which lead to lost data. Yes, knowing whether or not a certain version is indeed virgin can be a big problem.
So, does RR have similar issues? Is there a propensity for corruption to enter into files? If so, how do you deal with it?
Thanks for any insight on this.
Bill
corruption a problem here?
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
Janschenkel
- VIP Livecode Opensource Backer
- Posts: 977
- Joined: Sat Apr 08, 2006 7:47 am
- Contact:
Revolution actually always makes a new copy when it saves a stack: the existing stack is renamed (appending a tilde at the end), and then the stack is saved and if that goes well the backup is deleted - this way, if the engine crashes whiel saving, you won't end up with a half-baked stack.
That being said, the only corrupt stack that I've had so far in 7 years of Revolution, involved an image that I imported - and once that image was removed, my stack was all fine again.
Anecdotal evidence reveals that sometimes Revolution can even resurrect corrupted HyperCard stacks that HyperCard would choke on.
But backups are always good - and there's a free Altuit plug-in that takes incremental backups as you work. Get it at Altuit's Revolution Resources site: http://www.altuit.com/webs/altuit2/RunRev/default.htm
HTH,
Jan Schenkel.
That being said, the only corrupt stack that I've had so far in 7 years of Revolution, involved an image that I imported - and once that image was removed, my stack was all fine again.
Anecdotal evidence reveals that sometimes Revolution can even resurrect corrupted HyperCard stacks that HyperCard would choke on.
But backups are always good - and there's a free Altuit plug-in that takes incremental backups as you work. Get it at Altuit's Revolution Resources site: http://www.altuit.com/webs/altuit2/RunRev/default.htm
HTH,
Jan Schenkel.
Quartam Reports & PDF Library for LiveCode
www.quartam.com
www.quartam.com
-
FourthWorld
- VIP Livecode Opensource Backer
- Posts: 10049
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
I was hoping to be able to point you to some thorough posts from the use-rev list on this topic, but unfortunately the archives have been gzipped which makes them unusable for referencing individual posts via URL. I hope that changes back soon.
In the meantime, beyond echoing Jan's observations about the very rare infrequency of file corruption in Rev, I thought it might be useful to explain a bit about why that's the case:
FileMaker, HyperCard, and some other tools use a paging system to read and write files. This means that a portion is read into memory, and that portion written back into the file, usually where it was read from. When written to an errant location, corruption occurs.
In contrast, Rev stack files are read into memory in their entirety, and written back to disk in a single pass. And as Jan noted, before the new write begins it first backs up the last saved copy, preceeding it with a "~" character, and deletes that copy only after the new write is complete and a valid checksum verified. So if writing is interrupted, which would normally result in corruption, all you need to do is toss the bad copy, remove the tilde from the backup copy, and you're back in business as of your last successful save.
By writing the file in one pass, Rev is far less likely to make the sorts of mistakes that paging systems are unfortunately prone to.
So while Rev does provide the convenient backup copy of its stack files during save, like Jan I've very rarely needed it in more than 10 years of almost daily and often very intensive work.
In fact, I'd say that during this decade I've only seen one true instance of a corrupt object, and the rest of the file was just fine after I deleted that one object (related to a bug in QuickDraw which has long since been corrected for in the Rev engine). I've only heard about two cases of true file corruption during all those years.
So Rev's record is pretty good with regard to corruption. That said, it's still always a good idea to be making backups regularly for a host of other reasons (mostly, at least with me, caused by user error <g>).
In the meantime, beyond echoing Jan's observations about the very rare infrequency of file corruption in Rev, I thought it might be useful to explain a bit about why that's the case:
FileMaker, HyperCard, and some other tools use a paging system to read and write files. This means that a portion is read into memory, and that portion written back into the file, usually where it was read from. When written to an errant location, corruption occurs.
In contrast, Rev stack files are read into memory in their entirety, and written back to disk in a single pass. And as Jan noted, before the new write begins it first backs up the last saved copy, preceeding it with a "~" character, and deletes that copy only after the new write is complete and a valid checksum verified. So if writing is interrupted, which would normally result in corruption, all you need to do is toss the bad copy, remove the tilde from the backup copy, and you're back in business as of your last successful save.
By writing the file in one pass, Rev is far less likely to make the sorts of mistakes that paging systems are unfortunately prone to.
So while Rev does provide the convenient backup copy of its stack files during save, like Jan I've very rarely needed it in more than 10 years of almost daily and often very intensive work.
In fact, I'd say that during this decade I've only seen one true instance of a corrupt object, and the rest of the file was just fine after I deleted that one object (related to a bug in QuickDraw which has long since been corrected for in the Rev engine). I've only heard about two cases of true file corruption during all those years.
So Rev's record is pretty good with regard to corruption. That said, it's still always a good idea to be making backups regularly for a host of other reasons (mostly, at least with me, caused by user error <g>).
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn