LiveCode Forums.

Hello All,

I experienced a Low Virtual Memory warning dialog in XP. So I exited (gracefully) from RevMedia 4.0. Once I had exited all open apps, I restarted windows. When I re-opened RevMedia, I headed for the Open Recent File Menu which was strangely empty.

I then went file open and navigated to my stack, and upon attempting to open it was confronted with the dialog:

There was a problem opening the stack: stack is corrupted, check for ~ backup file, and on second attempt There was a problem opening that stack: stack was produced by a newer version.

I was able to reproduce the problem and logged it in the quality centre (all good).

I personally had a backup, and only lost a couple of hours work (not good but not critical).

Two questions if I may:

1. is there a utility to restore files reporting as corrupt or as a newer version?
2. does Rev save a local backup "~" file? where is it located? and under what circumstances is the IDE taking a backup.

Any assistance greatly appreciated.

Kind regards,

Andrew

What was the RQCC report number? I like to be aware of issues which may cause corruption.

The good news is that stack file corruption is extremely rare with Rev. We could get into why this is the case in more detail if you like, but for the moment suffice to say that with shipping versions of the engine I've only seen three actual cases of corrupt files since I started working with it in 1997.

The bad news is that your file is one of them.

Rev does make a backup file when the save command is executed, which is named the same as your stack file but preceeded with a tilde (e.g. "myproject.rev" is copied as "~myproject.rev") as you noted. As far as I can tell, the sequence goes something like this:

- the engine gets the save command
- makes a "~*" copy of the stack file
- writes your stack file to disk fresh from its contents in memory
- does a checksum on the file to verify that it's in good order
- after verifying, it deletes the "~*" copy

If the save is interrupted for any reason (power cutoff, force-quit, etc.), the stack file may not be complete and will be regarded as corrupt, but the "~*" copy will be in the same folder -- if you see that copy, in most cases you can safely quite Rev, move the corrupted file to the trash, remove the tilde from the copied file, and re-launch Rev to get back to work with everything in place as of your last successful save.

If you don't see a "~*" file in your directory, that seems to imply that the Rev engine thought it successfully wrote the file and has already deleted its backup. That would be bad news, requiring you to go back to your last manual backup to get back to work.

Given the variety of unpredictable things that can happen to a file, Rev has no built-in facility to attempting to restore them beyond its temporary backup file. If you have scripts or data there which may not be in your own backup versions, you can drop the stack file onto a text editor (or make a simple one in Rev in about a minute, just reading the stack file into a field), and copy out the portions of the scripts and data you need.

While the engine has a good track record with avoiding corruption issues, it should be noted that v4 adds new properties to the file format and is currently in an Alpha state, meaning it hasn't yet completed the testing needed to ensure its usefulness in the wild.

When working with any Alpha software you'll want to make backups regularly (I consider this a good practice for everything, backing up at least daily and for critical projects I often backup work files several times a day to a separate local drive).

This post may not be helpful for getting that file restored, but hopefully at least helps you better understand the role of the "~*" file and strategies for coping with potential corruption.

Please post the RQCC number when you have a chance. TIA -

Thanks Richard,

Ha ha - Due to loneliness I had almost stopped watching that post (many views before your reply), so your reply is greatly appreciated.

The RQCC report number is 8340: go

http://quality.runrev.com/qacenter/show_bug.cgi?id=8340

Thank you for your explanation as to the sequence of events when a stack is saved.

In my case no ~ backup files were present, and the original stack file had been truncated to 0 bytes. The checksum I presume was successful and the backup file removed.

My guess-planation (part guess and part explanation), is that a running Windows Update, and running Rev Media 4.0 brought about a situation of low virtual memory (the only other running app was IE, so a memory leak is possible), and during the save or exit, not enough memory (threads) were available for Rev to save in the usual manner. My guess then is that particular aspects of the save took place that allowed the checksum to succeed and remove the backup file. I speculate that the recent files menu is rebuilt as Rev exits. Rev I expect does some housekeeping in relation to that menu, and memory scarcity prevented that from happening. I have reproduced the "event" a few times now.

I purchased a licence for Enterprise 3.5 last week, so have been happily playing in that world since.

...and I hear loudly the message to obsessively backup - Thanks again.

Kind regards,

Andrew

Thank you for the URL to the report. I've added a vote there, as I consider all issues which can result in corruption to be extremely critical. You might consider adding some of your own votes to it to raise its visibility.

Your report mentions you're using an EeePC. I've been considering one of their netbooks for their ultra-portability, but am having difficulty finding a 901 with Linux in black. How do you like your Asus?

Hello Richard,

I didn't know I could (or thought it might be poor form) to vote for a bug ticket I had raised. I didn't want to upset a community I had just joined. Thank you for that.

In the last two years I have become a big fan of ASUS. Yes, I have always kept one current Mac on board, but having used Dell computers for years their offerings had become in my mind increasingly nonsensical for my purposes (and for most people IMHO).

Enter ASUS. When Asus brought out the EEE range, both desktop and laptop they ticked a few important boxes for me. I purchased the original EEEPC 701 laptop running Linux, as my companion when attending meetings and on the go, and it is great for network troubleshooting. Most importantly I needed low cost, well spec'd, low power consuming, quite machines for automated web tasks. The EEEBox (XP) are very inexpensive are inaudible, can attach to the back of a monitor and run unattended for days. So I bought a series of them and attached them to the back of my legacy Dell monitors. Now three of these babies do the work that almost 10 VPS did previously. These machines are not necessarily low spec'd (I would say right spec'd). I use another as my primary dev machine. But when testing software usability testing on lower end hw is important. These machines are a happy medium. Then I discovered another ASUS trick. They had a range of very cheap monitors, that connect to each other via usb to give you multiple monitor support without additional graphics cards (actually up to six monitors in series), but two monitors were enough to make life a little easier.

In my mind too the EEEPC laptops (ASUS were quite early movers in this marketplace) from the perspective of kids and education fulfil much of the promise OneLaptopPerChild vision of Negroponte, at least for the Western World. A bit more expensive perhaps, but a bit more relevant too. That's why netbooks are all the rage right now. You don't have to be in a third world to be price and feature conscious. Disadvantage lives everywhere. It is cool to see manufacturers provision to chase the not lesser but differently spec'd end of the market. Every child should have a PC, as they do make a difference, particularly in the development of math and logic.

Thanks again for your interest Richard.

Kind regards, Andrew

Andrew-

Don't know about Rev Media (haven't been playing around with it much after the initial launch) but I can verify that in the other versions of rev the recent files list is stored as a custom property in one of the IDE stacks. I've had stacks I was working on not added to the list after a crash (my coding fault, no blame on the IDE for this), but I've never (to my recollection) had the list emptied.

I think your theory of low-memory conditions sounds logical. I've had other low-memory problems, most frequently on linux, so I think there are areas where the rev engine doesn't handle error-checking very well under those situations. Page-swapping and threading issues could well be at fault, since rev expects everything it's working on to be in memory.

Thank you for your interest mwieder,

I have noted

the recent files list is stored as a custom property in one of the IDE stacks

, thank you for the heads up.

Kind regards, Andrew