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. 1. Download, configure, build and install the 20020111 snapshot, which didn't do anything for this problem. This problem being that when show or amcheck reads a tape label, it is not rewinding it for the next pass. The eject reload of a tape change will of course do this, but if amcheck finds a match, the tape was being left at block 64, where a label read by amdump then failed. IMO amdump really should have a rewind in front of its label reads, but I'm not sure where to put that. 2. Traceing through the sources, in tape-src/tapeio.c, in the function tapefd_readlabel(), I've added a call to tapefd_rewind(fd); above the tapefd_close(fd); call I can now run amtape /config/ show repeatedly, as well as amcheck /config/ repeatedly without errors. The question is: Is this automatic rewind in the tape-src/tapeio.c->tapefd_rdlabel(fd) function going to mess with anything else? IMO, not knowing all the fine points of how amanda is organised, it (to me) doesn't make any sense to do a readlabel without rewinding it for the next readlabel, in most cases it will come as a request from amdump to make sure its writing to the correct tape. So the question then is: will amdump then overwrite the tapes label after it reads it, gets a good one, rewinds to write the fresh one, writes it, rewinds to check it (maybe, I don't know if it does) with the end result being an overwritten label, overwritten by the dumps contents because the tape is NOT going to be left at block 64 after a tapefd_rdlabel(fd) as it was prior to this patch... Thomas, anybody else care to comment here? -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 98.3+% setiathome rank, not too shabby for a hillbilly
