Xref: utzoo comp.bugs.sys5:1000 comp.unix.questions:14122 comp.unix.wizards:16764 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mcnc!rti!tijc02!cgh018 From: cgh018@tijc02.UUCP (Calvin Hayden ) Newsgroups: comp.bugs.sys5,comp.unix.questions,comp.unix.wizards Subject: Interesting 'bug' in SysV Volcopy Message-ID: <491@tijc02.UUCP> Date: 7 Jun 89 15:13:15 GMT Distribution: usa Organization: Texas Instr., Johnson City TN Lines: 38 I recently ran across an 'interesting feature' in the volcopy command on our Sys V Rel2 Ver2 OS. The operator was running a set of disk compressions in which dcopy is used to compress the file system onto a spare drive, and volcopy is used to copy the file system back to its original drive after verification. The file system involved at the time of the 'feature encounter' was 1,190,000 blks (512 byte blks). After the std information ending with... From: /dev/rdsk/3s1, to: /dev/rdsk/2s1? (y or n) y the volcopy ran for 20 min or so, and then came back with the following... Changing drives? (type RETURN for no, `/dev/rmt_' or `/dev/rtp_' for yes: Baffled, he hit RETURN, and saw the following... Mount tape 2 Type volume-ID when ready: and so on. A nice feature when you are doing disk to disk volcopy. Our fix to volcopy.c was to remove the "#define MAX 1000000L" stmt, add "#include ", and change "long Reelblks=MAX" to "long Reelblks=MAXINT". The fix seems to have taken care of the prob... -- I mean feature. Question, anyone else run across something similar? Interestingly enough, after the fix, the original AT&T source would not compile due to 'missing 2 #endifs' which also had to be fixed -- made it look like the executable had been built from source other than we had, or source had later been modifed. Hmmmm. _____ | | o Calvin Hayden _____| \_ /___ Texas Instruments \ __/__ | Johnson City, Tn. - / \ UUCP: ...mcnc!rti!tijc02!cgh018 \_/--\ \/ _ / \ | \__\