m5@bobkat.UUCP (Mike McNally ) (05/22/87)
What's the point of the 's' (swap bytes) option to tar? Are there any
systems which store characters of a string in byte-swapped order (so
"TAMALE" looks like "ATAMEL")? I dig the scene with integers, man, but
strings? Far out. Especially since it swaps bytes in the header
blocks as well as in the data.
What's the strange message in the documentation about "blocked
archives"? (All these things are about BSD tar, not System V. By the
way, how close is System V tar format to POSIX USTAR format?)
--
Mike McNally, mercifully employed at Digital Lynx ---
Where Plano Road the Mighty Flood of Forest Lane doth meet,
And Garland fair, whose perfumed air flows soft about my feet...
uucp: {texsun,killer,infotel}!pollux!bobkat!m5 (214) 238-7474mdb@laidbak.UUCP (Mark Brukhartz) (05/24/87)
> From: m5@bobkat.UUCP (Mike McNally ) > ... > What's the point of the 's' (swap bytes) option to tar? Are there any > systems which store characters of a string in byte-swapped order (so > "TAMALE" looks like "ATAMEL")? I dig the scene with integers, man, but > strings? Far out. Especially since it swaps bytes in the header > blocks as well as in the data. > ... Several Motorola 680x0 systems with an Intel Multibus actually make tapes with every byte pair swapped. It seems that Motorola and Intel believe in different byte orders. The Multibus is word-oriented; hence, byte order is significant. This affects the memory-mapped control registers, DMA'ed control structures ("IOPBs"), and, of course, the data. Some Multibus controllers have switches to reverse their byte order (presumably by inverting the low-order address bit on the bus). Typically, though, the magtape driver must do this the hard way. The usual solution is to byte-swap the data before the DMA and to restore it afterwards. For odd-boundary transfers, the odd-addressed byte(s) must also be swapped with their neighbors. These could be at the beginning of the data (odd address, odd length), at the end (even address, odd length), or at both ends (odd address, even length). Needless to say, several drivers handle the general case, but botch odd boundaries. Of course, a few systems (especially early ones) ignore the problem entirely. They read and write tapes with reversed byte order. (They also corrupt data which begins or ends at odd addresses.) Mark Brukhartz Lachman Associates, Inc. ..!{ihnp4, sun}!laidbak!mdb
guy%gorodish@Sun.COM (Guy Harris) (05/25/87)
> What's the point of the 's' (swap bytes) option to tar? What 's' option to "tar"? There isn't one in the 4.2BSD "tar", nor in the 4.3BSD "tar", nor in the S5R2 "tar", nor in the S5R3 "tar". > What's the strange message in the documentation about "blocked > archives"? From the S5R2 "tar" manual page: The "b" option should not be used with archives that are going to be updated. The current magnetic tape driver cannot backspace raw magnetic tape. Similar words appear in other versions of the manual page. Since the 4BSD magtape drivers support an "ioctl" to do special functions such as backspace, the 4BSD "tar" was modified to use this "ioctl", and the restriction in question was listed. > By the way, how close is System V tar format to POSIX USTAR format?) Except for the absence of a format code for symbolic links, it is exactly as close to the POSIX format as the 4BSD format is, since they are the *same* format. (The symbolic link code is reserved, not specified, by the POSIX format, since POSIX doesn't describe symbolic links.) Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
chris@nrcvax.UUCP (05/26/87)
m5@bobkat.UUCP (Mike McNally (Man from Mars)) says: >What's the point of the 's' (swap bytes) option to tar? Are there any >systems which store characters of a string in byte-swapped order (so >"TAMALE" looks like "ATAMEL")? I dig the scene with integers, man, but >strings? Far out. Especially since it swaps bytes in the header >blocks as well as in the data. Yes, there are systems out there that do byte swap. Go check out Integrated Solutions. (Why they do this is beyond me. It's not directly compatible with any other system we have.) And yes, they byte swap everything, including the header blocks. -- Chris Grevstad {sdcsvax,hplabs}!sdcrdcf!psivax!nrcvax!chris ihnp4!nrcvax!chris As Mad Max was wont to say: So-so-so-so-so-so-sorry about that, Chief!
woods@hao.UCAR.EDU (Greg Woods) (05/28/87)
In article <926@nrcvax.UUCP> chris@minnie.UUCP (Chris Grevstad) writes: >Yes, there are systems out there that do byte swap. Go check out Integrated >Solutions. (Why they do this is beyond me. It's not directly compatible with >any other system we have.) We have such an Integrated Solutions machine, and the swapping option is quite nice for writing VAX-compatible tapes (our users are used to VAX byte order and receive many such tapes in the mail for analysis). Of course, since I.S. allows you to have the byte swapping done in the device driver (by using /dev/srmt0 instead of /dev/rmt0, etc.), we just switched the device names around to make VAX byte order the default for tapes. It works great. --Greg -- UUCP: {hplabs, seismo, nbires, noao}!hao!woods CSNET: woods@ncar.csnet ARPA: woods%ncar@CSNET-RELAY.ARPA INTERNET: woods@hao.uun.thont
guy@gorodish.UUCP (05/28/87)
> We have such an Integrated Solutions machine, and the swapping option is > quite nice for writing VAX-compatible tapes (our users are used to VAX byte > order and receive many such tapes in the mail for analysis). It's not "VAX-compatible" and "VAX byte order". It's not a question of the byte order of your machine. IBM 360s and Suns, to give two examples, are big-endian machines, but they write character strings onto magtapes in the same way that VAXes do - character N+1 follows character N on the tape. Everybody *should* write tapes in this fashion; unfortunately, not everybody does. I don't have any of the ANSI standards on mag tape handy to see whether they require this; it would be nice if they did. (Note that the ANSI standards for labelled tapes are intended to permit tapes written on one machine to be read on another machine. The labels on these tapes are full of character strings, so if you write your tape in the wrong order you are certainly contravening the spirit, if not the letter, of the ANSI standard.) Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
gnu@hoptoad.UUCP (05/29/87)
In article <697@hao.UCAR.EDU>, woods@hao.UCAR.EDU (Greg Woods) writes: > We have such an Integrated Solutions machine, and the swapping option is > quite nice for writing VAX-compatible tapes (our users are used to VAX byte > order and receive many such tapes in the mail for analysis). Of course, > since I.S. allows you to have the byte swapping done in the device driver > (by using /dev/srmt0 instead of /dev/rmt0, etc.), we just switched the device > names around to make VAX byte order the default for tapes. It works great. Ho ho! There is no such thing as "VAX byte order on tapes". There is just "correct byte order on tapes". The standards for 1600 bpi tapes were defined by IBM years and years ago, and the bytes are in a very certain order. E.g. if you write (hex) 0001020304050607 to a tape, the bytes come out 00, then 01, then 02, etc. Never 01, 00, 03, 02, ... It sounds like Integrated Solutions ships their systems with "incorrect byte order on tapes" as the default, and then claims that the ability to fix it is a feature. One will get you five that they are using a Tapemaster tape controller, like Plexus, the other system known to have this bug. At least they provide the swap option in the driver; Plexus makes you do it with dd, and doesn't document that it isn't compatible with anybody else's systems. On reasonable systems using the Tapemaster, of course, the "swap option in the driver" is not an option, it's always on. You can cry about the performance loss, but "I can make it arbitrarily fast, if you'll accept the wrong answer!" -- Copyright 1987 John Gilmore; you may redistribute only if your recipients may. (This is an effort to bend Stargate to work with Usenet, not against it.) {sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu gnu@ingres.berkeley.edu
bandy@amdcad.AMD.COM (Andy Beals) (05/29/87)
In article <1003@bobkat.UUCP> m5@bobkat.UUCP (Mike McNally (Man from Mars)) writes: >What's the point of the 's' (swap bytes) option to tar? Are there any >systems which store characters of a string in byte-swapped order (so >"TAMALE" looks like "ATAMEL")? I dig the scene with integers, man, but >strings? Far out. Especially since it swaps bytes in the header >blocks as well as in the data. Well, I don't know what version of tar you're using (I checked both our UTS and 4.3 systems), becuase I've never heard of that option before, but I think that it is a useful one. When I came here to work at AMD, I found out that not everyone who can design a 1/2" tape interface can get the bytes in the right order. Some time in the deep dark past, AMD chose Valid as their workstation to pass out to chip design teams. They didn't notice anything funny then, but once AMD started hooking all the workstations together with tcp/ip, they noticed that the file format for all of the data files had the bytes swapped! Also, if you do (cd $src ; tar crf - .) | rsh destmach "(cd $dest ; tar xfB -)" it wouldn't work. If you ftp over a big tar file it won't work either. But if you say dd if=big.tar.file conv=swab | tar xf - It works just fine. So what happened here? The people who designed their magtape interface got the bytes backwards. And what happened then? The PINHEADS at Valid didn't put a swab down in the driver or simply switch the wires coming out of the interface, THEY PUT A SWAB INTO EVERY SINGLE PROGRAM THAT USED DATA FROM MAGTAPE! When I heard that, I couldn't believe it; who could be so pinheaded? But it is true and every time I go and write another utility, I have to have it peek aroudn the system to see if it's running on one of those damnable Valids and put swabs in. ICK. Now we're "upgrading" to apollos, bu the valids will still be around. -- Andrew Scott Beals, {lll-crg,decwrl,allegra}!amdcad!bandy +1 408 749 3683