I'm using the 3-hole label template. Amanda version is 2.5.0p2 from zmanda on Fedora 4.
I'm taping to vtapes and tape spanning is turned on. Though I seldom exceed one tape the dumps are still split into tape_splitsize chunks. It appears to me that the "File #" column in the report is meaningless, except for the ordering of the dumps on the tape. The numbers simply increase by 2 for each DLE. So File #0 is the tape header, #2 is the first DLE dump, #4 is the second DLE etc. It doesn't matter if the DLE took 1 split or 50, the next File # is increased by 2. On physical tapes I would have expected these File #'s to allow me to "mt fsf" to that # and extract the dump I wanted. Clearly that is not the case for my reports. To confirm this I used ammt rewind and ammt fsf to advance to several file numbers. When I used amdd to read the vtape header it matched the 5 digit file numbers on disk rather than the "File #" from the printed report. Is it my misunderstanding of the report's File # or some problem generating the numbers? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road (609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
