CompuServe Messages

The first problem is explainable. When I originally wrote saf-T-net, I made a conscious decision to perform all accessing of the data on the Hard Disk via the AmigaDOS file system. This allows saf-T-net to work on all hard disks that support the AmigaDOS file system. This is also why saf-T-net works without problem with the "hopefully to appear soon" Fast File System, even though it didn't exist when saf-T-net was first written. The only problem with this approach is that if you have a bad file that AmigaDOS can't read, saf-T-net can't read it either. It is in fact AmigaDOS, not saf-T-net, that is GURUing. The way around this is to use the wildcard pattern matching capabilities (fully described in the manual) to Exclude the bad file from being backed up. This will allow the rest of the partition to be backed up. As to the second problem, I can't see offhand why that scenario should cause a GURU – saf-T-net will do exactly what you had asked it to do – there's nothing 'wrong' in what you asked, just not what you had intended. As to the disk being unreadable – is it in fact "unreadable", or just not recognized as the last disk in the backup set? In the latter case, you can (most likely) still read and restore the data from the disk, you just won't be able to append onto it. In the former case (i.e., the disk is totally unreadable by saf-T-net), then unfortunately the data on that disk is gone. I haven't seen this situation myself, but it would be possible (if Track 0 were trashed). I sure hope this is not the case. If you can help me find a way to reproduce this second GURU, I'll be glad to try to hunt it down and kill it. (The first, I can't do a lot about, since I can't "fix" AmigaDOS). Thanks for your interest in saf-T-net. I hope this helps. ..Bob