RISC OS 5.18 Freeze and disc corruption

I have been using RComp’s SafeStore on my Iyonix PC for ages without problem but when I upgraded RISC OS to 5.18 I have been having severe problems.

I have SafeStore 2.06 set to automatically backup two folders at different times every day. This is from ADFS::4 to ADFS::5 – Since using RISC OS 5.18 (flashed) SafeStore freezes during most scheduled backup processes. The freeze corrupts ADFS::4 shown by running DiscKnight afterwards. I then have to use DiscKnight to repair ADFS::4 – I also verified the disc and there are no
physical problems with it.

Andrew at RComp doesn’t see how there could be a problem with SafeStore as it doesn’t do anything to cause disc corruption AFAIK since it is merely copying files.

After several days of disc mayhem, I had to stop using SafeStore and changed to using 7Backup instead which works faultlessly backing up the same directories. I also use Organizer to schedule the backups automatically every day. Since changing to 7Backup and Organizer I have had no further freezes or disc corruptions.

Is there a known problem with RISC OS 5.18 to cause these problems – or has something changed in the way files are copied in 5.18 and SafeStore can’t cope with this change please?

I think it is worth observing that it works fine on the programmer’s Iyonix, and on a number of ARMinis. However, it could be related to ADFS>ADFS – most people will be backing up to network drive or other filing system (or SCSIFS on an ARMini).

From your message you have to repair disc 4 which is only being read from, except for creation of the backup tree. That’s somewhat of a strange way round. It would be helpful to know what part of ADFS:4 is being repaired.

ADFS::4 is my main drive and ADFS::5 is my backup drive.
I don’t know what’s strange with that.

It seems to be random parts and quantities of repairs being needed after a freeze. Occasionally from within the directory being backed up and also completely outside from within another directory not being backed up. One of the freezes produced hundreds of errors. I’ve long since deleted the ‘lostandfound’ contents and log file after I restored the corrupted bits from my backup drive, so can’t be more precise.

You’re missing my point, Bernard – if no writing is going on (main drive is where data is being read from), it doesn’t make much sense that it would corrupt (which usually requires writing). Except that the job tree is stored there. This makes me wonder if something else were writing to the disc at the same time? Read operations shouldn’t produce disc corruption!

So what Andrew is asking is: is it possible to know which bit(s) of the disc DiskKnight is finding the errors with or repairing? It could be a bug in the job tree creation code in SafeStore, or a bug introduced in 5.18 which we need to know about ASAP. Or you could be unlucky and hitting a broken bit of disc everytime SafeStore runs for some reason.

[Admin deleted duplicate post]

As I said, I don’t have the DiscKnight log or the ‘lost and found’ directory any more. I had to delete it fairly quickly as it had filled up my hard disc. I have around 6GB free at the moment and at the times of the freeze.

I do remember though that there were no disc errors in !Boot which is presumably where SafeStore writes its job tree. My !Boot.Choices.SafeStore folder is currently 48,827,290 bytes in size if that helps. I also remember that there were no disc errors in $.Apps.!SafeStore

That does sound rather large for a SafeStore choices folder – I guess you must be using it to image the whole drive rather than just the parts that change regularly (as recommended in the instructions). It shouldn’t be a problem, but you could try using the “one off” backup feature to back up the whole drive, then set up separate backup jobs for !NewsDir and your main work folders, and see if that helps.

Would also be interesting to see if the problem occurs during the “one off” backup job, as opposed to a scheduled “update”.

I already have my backup jobs setup like you suggest.
I have 6 SafeStore backup jobs, 2 of which are smaller scheduled jobs and are the ones mentioned above that cause the freeze. I only do the other 4 backup jobs manually occasionally. One of these other 4 is the
whole drive to a NAS drive. The manual backup jobs (or scheduled jobs done manually) haven’t frozen so far.