Forum unknown
· Amiga at Work
Saf-T-Net
11 messages in this thread
Bob,
I just purchased Saf-T-Net and although it's the best back-up program I've
seen yet, I have run into a couple of problems.
1) I had an unreadable file on dh1. When Saf-T-Net ran into it while backing
up I got the "read/write error" system requester. I selected cancel, then got
a GURU.
2) I was doing a incremental backup of DH1: but forgot to change the backup
node. (which defaults to DH0:) The index for DH1: was already loaded.
Saf-T-Net read one file from DH0: then wrote to the backup disk and GURU'ed.
This left the backup disk unreadable.
BTW, Both of these problems are repeatable.
I have Ver. 1.02.
Dale
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
Bob,
I played with the problems some more and found another unreadable file on
DH0: which is what really caused problem 2.
I still don't quite understand why Saf-T-Net can't just skip a bad file and
go on to the next. Problem 1, where I canceled the "read/write" requester.
The bad file was a IFF picture. If I try to display the picture with
ViewILBM I still get the requester, but when I cancel, ViewILBM gives me a
error msg and then exits. This is the same file that Saf-T-Net guru's on. I
don't think the guru is coming from ADos. Also GOMF removes Saf-TNet on the
guru. (I believe GOMF reported "run-away code" as the cause.)
I really like the program. Not being critical, just trying to help:)
Dale
Dale,
OK – I understand what you are saying. It does sound like there's a problem
in saf-T-net, then. I'll definitely look into this one, cause it shouldn't
GURU in that case, it should just bypass that file and go on to the next one.
Sounds like a bad return code is slipping through somewhere. (how'd that one
get by?)
Thanks for the report.
..Bob
Dale,
OK – I understand what you are saying. It does sound like there's a problem
in saf-T-net, then. I'll definitely look into this one, cause it shouldn't
GURU in that case, it should just bypass that file and go on to the next one.
Sounds like a bad return code is slipping through somewhere. (how'd that one
get by?)
Thanks for the report.
..Bob
Bob,
I played with the problems some more and found another unreadable file on
DH0: which is what really caused problem 2.
I still don't quite understand why Saf-T-Net can't just skip a bad file and
go on to the next. Problem 1, where I canceled the "read/write" requester.
The bad file was a IFF picture. If I try to display the picture with
ViewILBM I still get the requester, but when I cancel, ViewILBM gives me a
error msg and then exits. This is the same file that Saf-T-Net guru's on. I
don't think the guru is coming from ADos. Also GOMF removes Saf-TNet on the
guru. (I believe GOMF reported "run-away code" as the cause.)
I really like the program. Not being critical, just trying to help:)
Dale
Bob:
I have not yet looked for an answer but while trying to recover a partition
that was trashed a couple of nights ago — and no I don't know who to blame
for sure though "movie" is the current suspect. A well unknown term program
was running but had been idle for hours and an attempt to repeat the event on
a floppy failed to provide any ill events (still have not had time to do the
backup).
Block 0 of the partition had obviously been trashed and while looking
around prior to making any changes to the block, I noticed that every block
0 on every disk or partition had the same checksum and that the checksum
was listed as "bad" by two diskeditors. I did not bother to restore the
complete block and don't think that I could have "forced" the checksum
except by playing with the data which would have been tedious at best. My
real surprise was when after correcting the first 4 bytes and getting a
valid checksum (but of course different from all of the others) the partion
was readable. It appears that the system one, ignores the checksum value
in the first block and two, either does not actually calculate a checksum
for the first block or uses a different formula. Am I dreaming?
I'm not sure why your question was directed to me, or attached to a saf-T-net
thread. I'm not real knowledgable about the AmigaDOS disk structures, but I
think that the 'checksum' that these disk editors use/refer to (looking in
the AmigaDOS Tech. Ref. Manual – LongWord 5 of the sector) does not apply to
the Boot block on the disk partition (Block 0). For a non-bootable disk (or
partition), the contents of the Boot Block are meaningless, except for the
first four bytes, which identify the type of disk it is ==> "KICK" for a
Kickstart disk, "DOS " for a standard AmigaDOS disk, and anything else for a
"Not a DOS disk".
Are you dreaming? I don't know – what was that funny little pill I saw you
taking? <grin>
I'm not sure why your question was directed to me, or attached to a saf-T-net
thread. I'm not real knowledgable about the AmigaDOS disk structures, but I
think that the 'checksum' that these disk editors use/refer to (looking in
the AmigaDOS Tech. Ref. Manual – LongWord 5 of the sector) does not apply to
the Boot block on the disk partition (Block 0). For a non-bootable disk (or
partition), the contents of the Boot Block are meaningless, except for the
first four bytes, which identify the type of disk it is ==> "KICK" for a
Kickstart disk, "DOS " for a standard AmigaDOS disk, and anything else for a
"Not a DOS disk".
Are you dreaming? I don't know – what was that funny little pill I saw you
taking? <grin>
Bob:
I have not yet looked for an answer but while trying to recover a partition
that was trashed a couple of nights ago — and no I don't know who to blame
for sure though "movie" is the current suspect. A well unknown term program
was running but had been idle for hours and an attempt to repeat the event on
a floppy failed to provide any ill events (still have not had time to do the
backup).
Block 0 of the partition had obviously been trashed and while looking
around prior to making any changes to the block, I noticed that every block
0 on every disk or partition had the same checksum and that the checksum
was listed as "bad" by two diskeditors. I did not bother to restore the
complete block and don't think that I could have "forced" the checksum
except by playing with the data which would have been tedious at best. My
real surprise was when after correcting the first 4 bytes and getting a
valid checksum (but of course different from all of the others) the partion
was readable. It appears that the system one, ignores the checksum value
in the first block and two, either does not actually calculate a checksum
for the first block or uses a different formula. Am I dreaming?
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