On Sunday 13 January 2002 01:54 pm, Thomas Hepper wrote:
>Hi Gene
>
>On Sun, Jan 13, 2002 at 12:17:27PM -0500, Gene Heskett wrote:
>> On Thursday 10 January 2002 02:31 pm, Thomas Hepper wrote:
>> >To change this will take some time, i think you will hear
>> > from me tomorow,
>>
>> I hadn't heard,  my cold isn't any better and the backup
>> schedule restarts tonight for the week.  Here is what I've
>> done, and which *appears* to have fixed this problem.
>
>Sorry, but we had a crash of one database system on my work
> which took all me time (include free time at home). It was/is
> important that system will stay online forthe weekend, some
> most of my time this weekend is used by looking at this system
> ...., sorry, but work is more important.

Of course!
>
>I will read you posts and if nothing bad happens you will hear
>from me on monday.

Well, I've been thinking on this, and it makes more sense to do 
the rewind before the label read, therefore leaving the tape at 
block 64 when done.   The incorrect assumption that the tape 
actually has ben rewound when the tape_rdlabel(fd); is attempted 
seems to be the problem.

So I will interchange those two statements in the tapeio.c 
sources, which will then do a dummy rewind with no errors 
returned before reading the label, and will leave the tape in the 
same position when done as before, eg at block 64.

To refresh the users-list, in tapeio.c, the function 
tape_rdlabel() now looks like this:

char *
tape_rdlabel(devname, datestamp, label)
    char *devname;
    char **datestamp;
    char **label;
{
    int fd;
    char *r = NULL;

    if((fd = tape_open(devname, O_RDONLY)) < 0) {
        r = errstr = newvstralloc(errstr,
                                  "tape_rdlabel: tape open: ",
                                  devname,
                                  ": ",
                                  strerror(errno),
                                  NULL);
    } else tapefd_rewind(fd); /* a dummy rewind to make sure it 
is, by G. Heskett */
    if(tapefd_rdlabel(fd, datestamp, label) != NULL) {
        r = errstr;
    }
    if(fd >= 0) {
        tapefd_close(fd);
    }
    return r;
}

That code is now building, and will be tested by seeing if an 
error can be induced by doing a dd read of the label before 
starting an amcheck or amshow.
Now here is an odd one, I did that editing as amanda, but when I 
make it, I get all sorts of questions from the compiler about 
changing the perms from 0644, so I've been exiting to root, and 
doing a chown -R amanda:amanda * in the top sourcedir.

But that time I just changed the whole damned system because I 
didn't note the path bash printed when I exited user amanda.  
This will take a while to sort, and frankly, I'd druther sort 
rattlesnakes.  They're more predictable.

And my test of running dd to read the label in front of an 
amcheck now works with or without the dd first.

Comments please!

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
98.3+% setiathome rank, not too shabby for a hillbilly

Reply via email to