Return to BSD News archive
Xref: sserve comp.os.linux.development:8335 comp.unix.bsd:13791 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!yarrina.connect.com.au!warrane.connect.com.au!kralizec.zeta.org.au!not-for-mail From: nick@kralizec.zeta.org.au (Nick Andrew) Newsgroups: comp.os.linux.development,comp.unix.bsd Subject: TIP: Compiling 'mt' (from Gnu cpio 2.3) for remote mag tape I/O Date: 30 Apr 1994 15:16:09 +1000 Organization: Kralizec Dialup Unix Sydney: +61-2-837-1183 V.32bis Lines: 29 Message-ID: <2pspip$30h@kralizec.zeta.org.au> NNTP-Posting-Host: kralizec.zeta.org.au Summary: Be careful if your mtio.h does not match the remote system I need remote tape access (in particular, backing up my Linux filesystems over the net) so I compiled Gnu's cpio-2.3 for Linux. My Sun workstation running 4.0 has a tape drive, my Linux box doesn't. 'mt' and 'rmt' in this distribution come from Berkeley. On testing the 'mt' program (Linux) vs. 'rmt' (SunOS) I found that the numbers for magtape ioctls (WEOF, ERASE, RETENSION) etc. are quite different between SunOS (4.0) and Linux. This can be quite a problem because the 'mt' command makes ioctl requests to 'rmt' by number rather than by symbolic name. Request retension and get erase? Yuk! The solution in my case was to copy the SunOS <sys/mtio.h> file to "mtio.h", hack the sources to include that and recompile/relink. That fixed everything (except for an "Operation not permitted" error at the end of cpio) for tape I/O from my Linux box. Should I add a SCSI tape to my Linux box however, the above fix will break 'mt' for local tape operations. It's almost worthwhile fixing or extending 'rmt' to recognise symbolic names for tape I/O operations and then modify 'mt' (and rtapelib) to perform some sort of feature test before issuing any remote ioctl requests. Nick. -- Kralizec Dialup Unix (Public Access) Data: +61-2-837-1183, 837-1868 Zeta Microcomputer Software v.42bis v.32bis 14.4k 24 hours P.O. Box 177, Riverstone NSW 2765 Plan: To beat Gnuchess 4.0 fairly!