Fatal - all links get lost in case of power cut

This is a huge trouble, because everytime the computer turns off suddently the FRD loses all its links in the main window when started again. What this means is that you lose information which of them have been already downloaded and which of them have not (+ the sizes of the files). In case of a huge list this means hours of additinal time spent trying to renew the list correctly just because of this.

Could you change the code somehow so that this does not happen even when the FRD is turned off suddently?



Edited 1 time(s). Last edit at 08/15/2010 05:55AM by maiki.

It works fine to us.

-------------------------------------

Perhaps, if I backed up the link-list back up file before opening FRD after "crash" and renamed the file - would that help?

It works fine even i kill it through task manager.

-------------------------------------

Vity, i have confirmed that the links list - filesList.xml goes blank after restarting following a power loss or case button shutdown for system lockup. This is a code bug.

Please fix this. Thanks

It obviously doesn't go blank all by itself.

Can you test it by forcibly shutting it down, backing up filesList.xml, making sure it's blank on FRD startup, and then send the backup to us?

Note, i haven't looked at code yet. I only observed the behavior in FRD folder.
I tested with a download in progress and long list of 2700 links to slow down the updating process.

Summary: Instability from too long of link list. The time required to update filesList.xml and filesList.xml.backup event is vulnerable to a power loss causing loss of memory. This causes a 0'd second half of filesList.xml.backup data and missing filesList.xml. Restart of FRD then shows no list. the newly created filesList.xml is the same as the corrupted backup.

This really isn't an issue using less than 1000 links. However, I recommend splitting the backup update from every second filesList.xml save during download event, to their own separate events fired from from JTable data change event. Then during prog start test the files, compare data, send a msg to user to select backup.

I'll look at the code later and submit ideas to help.

I still don't see a problem.

-------------------------------------

The problem is: you have a "call" to update the filesList within a ~file downloading in progress~ type routine.

Each iteration of this loop the filesList gets held in memory deleted and rewritten every time. With a long list that loop gets slowed down to 7 seconds (vulnerable to power loss). [You can watch this happen in real time in the folder with a long list] Note, that the backup saves every other iteration.

Why the filesList file is gone after power failure and backup file's 2nd half turns to all 0's, is for an engineer to explain. But probably has to do with being held in memory, blocks, and the save process.

With a short list this iteration occurs many times a second. This continuous write cycle creates unnecessary hard drive wear and tear and a waste of system resources.


Note, for anyone who lost their list. rt click the FRD folder in [user]\AppData\Roaming\VitySoft. select properties. select previous versions tab. recover an earlier version of folder from restore point. replace folder.