jim@jagubox.gsfc.nasa.gov (Jim Jagielski) (05/28/91)
Many moons ago (well, a few then) there was a discussion here on c.u.a
concerning the "best" way to copy entire file systems: tar, cpio, dump.bsd or
whatever. I wrote that, IMHO, using tar didn't make sense, since it has trouble
with special file types; using find and cpio required filtering out the mount
point of the new file system to prevent copying copys. Now this isn't all that
difficult, but it does add a level of complexity and it DOES change file time-
stamps, which may not be such a good thing. I suggested that using dump.bsd and
restore in a simple pipe was the way to go:
$ dump.bsd -t 4.2 0uf - /dev/rdsk/cxdysz | (cd /mnt; restore -T 4.2 xf - )
Of course, you could dump to tape and then restore from it, but this takes much
longer.
Well, I just moved my A/UX system to 2 335 MB Wren Runners using the above
method and I have a few observations to share:
1. This method, more specifically restore (I think) had trouble
"copying" named pipes. In my configuration there were only
2 (lib/cron/FIFO and lpd/AppleTalk/pipe) and after the dump/restore
I simply copied them over... restore said something about an
"unknown mode 010xxx" where xxx was either 660 or 666.
2. All symbolic links were (re-)created with an owner and group of
root. Of course, this really doesn't matter, since the owner, group
and mode of a link doesn't mean all that much, but it still is
a change over what the file-system looked like before...
Everything else went off without a hitch...
Oh yeah, by the way. The correct /etc/disktab entry for the 335MB Wren Runner
(ST 4385D, 385H: 94181-385) is:
# Wren 4385
#
WR385|Runner|ST4385:\
:ty=winchester:ns#56:nt#15:nc#791:
At least, that's what the Seagate spec-sheet says :)
--
===========================================================================
#include <std/disclaimer.h>
=:^)
Jim Jagielski NASA/GSFC, Code 711.4
jim@jagubox.gsfc.nasa.gov Greenbelt, MD 20771
"If we increase the size of the penguin until it is the same height as a man
and then compare the relative brain size, we know find that the penguin's
brain is still smaller. But, and this is the point, it is larger than it WAS!"tony@tui.marcam.dsir.govt.nz (Tony Cooper) (05/28/91)
|> 1. This method, more specifically restore (I think) had trouble |> "copying" named pipes. In my configuration there were only |> 2 (lib/cron/FIFO and lpd/AppleTalk/pipe) and after the dump/restore |> I simply copied them over... restore said something about an |> "unknown mode 010xxx" where xxx was either 660 or 666. |> |> 2. All symbolic links were (re-)created with an owner and group of |> root. Of course, this really doesn't matter, since the owner, group |> and mode of a link doesn't mean all that much, but it still is |> a change over what the file-system looked like before... |> These aren't flaws with the dump method. They are BUGS with the dump and restore programs. Better read up on that SPR stuff. Thanks for pointing this out. I`ll include this information in my Tips, Tricks, and Hints compilation. For readers: trivial bugs like these aren't too trivial to post in this newsgroup (in my opinion). Or to send to me for my compilation. Somewhere, sometime, when you least expect it, you are going to be hit by something trivial like this. Tony Cooper sramtrc@albert.dsir.govt.nz <- the address to send your tips, tricks, hints, and spare CDROM drives.
jim@jagubox.gsfc.nasa.gov (Jim Jagielski) (05/28/91)
In article <1991May28.122741.2230@am.dsir.govt.nz> sramtrc@albert.dsir.govt.nz writes: } }|> 1. This method, more specifically restore (I think) had trouble }|> "copying" named pipes. In my configuration there were only }|> 2 (lib/cron/FIFO and lpd/AppleTalk/pipe) and after the dump/restore }|> I simply copied them over... restore said something about an }|> "unknown mode 010xxx" where xxx was either 660 or 666. }|> }|> 2. All symbolic links were (re-)created with an owner and group of }|> root. Of course, this really doesn't matter, since the owner, group }|> and mode of a link doesn't mean all that much, but it still is }|> a change over what the file-system looked like before... }|> }These aren't flaws with the dump method. They are BUGS with the dump and }restore programs. Better read up on that SPR stuff. } Oh great... and what other bugs are there in dump/restore? Must I list every file on my system and make sure that the owner, group and modes are correct? Did dump/restore not copy other files and "forget" to tell me? Should I stay awake at night pondering the REAL status of my new system?? -- =========================================================================== #include <std/disclaimer.h> =:^) Jim Jagielski NASA/GSFC, Code 711.4 jim@jagubox.gsfc.nasa.gov Greenbelt, MD 20771 "If we increase the size of the penguin until it is the same height as a man and then compare the relative brain size, we know find that the penguin's brain is still smaller. But, and this is the point, it is larger than it WAS!"
liam@cs.qmw.ac.uk (William Roberts;) (05/29/91)
In <5444@dftsrv.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes: >}These aren't flaws with the dump method. They are BUGS with the dump and >}restore programs. Better read up on that SPR stuff. >} >Oh great... and what other bugs are there in dump/restore? Must I list every >file on my system and make sure that the owner, group and modes are correct? >Did dump/restore not copy other files and "forget" to tell me? Should I stay >awake at night pondering the REAL status of my new system?? Yes and no. In any hybrid system such as A/UX, where you import code and facilities from two radically different sources, there is a possibility that not quite everything got merged properly. The dump/restore/cpio/tar facilities seem to have been quite badly hit by all this, specifically: SYSV - FIFOs, short filenames, effective group id used during file creation cpio, SYSV version of dump & tar BSD - symbolic links, long names, UNIX domain sockets, group id of parent directory used during file creation, BSD version of dump & tar In A/UX 1.1 there were bugs in the way that cpio (SYSV) handled symbolic links (BSD). The old SASH version of fsck didn't understand UNIX domain sockets. There is a fundamental design problem with tar in that it limits pathnames to 1023 bytes (or thereabouts), which isn't long enough if people have Mac filesystems on top of BSD filesystems (e.g. using CAP) and they go in for meaningful names. It is disturbing when archiving utilities don't work properly, but these programs are generally pretty paranoid and so they don't keep quiet about your problems: the worst I've encountered was the cpio bug with symlink handling, which could actually end up changing the permissions on your *original* files to something like 777, but this has been fixed in 2.0 (maybe even 1.1.1). PS. That "pax" program suffers from an assortment of these bugs, and furthermore it doesn't really behave the same way as either cpio or tar. I used to have cpio and tar as symbolic links to pax, but eventually went back to the real things. -- William Roberts Internet: liam@dcs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-dcs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: +44 71-975 5234 (Fax: +44 81-980 6533)
alexis@panix.uucp (Alexis Rosen) (06/09/91)
jim@jagubox.gsfc.nasa.gov (Jim Jagielski) wrote (a few weeks ago): > >Oh yeah, by the way. The correct /etc/disktab entry for the 335MB Wren Runner >(ST 4385D, 385H: 94181-385) is: > # Wren 4385 > WR385|Runner|ST4385:\ > :ty=winchester:ns#56:nt#15:nc#791: Not according to Apple. The entry supplied by A/UX says: # MicroNet SBX330 # MN330|mn330|SBX330:\ :ty=winchester:ns#46:nt#9:nc#1409: The MicroNet is none other than this Wren 4385. So which is right? More to the point, how can any of them be right? This disk, along with all of the new big Wrens (and now other manufacturers' models too) uses ZBR, which puts different numbers of sectors on various sets of cylinders. How do you decide what to do in such a case? We have one of these Wrens, and we also have a 630MB Wren with ZBR. I just used the Generic entry for that one. Was there a better approach? --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY alexis@panix.com {cmcl2,apple}!panix!alexis