Mac OSX Terminal dump/restore question
Mark Conrad
Specifically the restore command.
I am trying to do a level zero dump and restore of a UFS volume on an
external drive.
My boot drive is an internal drive.
I obtained the 'real' partition numbers of these two partitions of the
external drive, "WD-Orig" and "WD-OrigBack" using pdisk:
sudo pdisk /dev/disk1 -dump
WD-Orig is the original partition I want to back up, it is 51.2MB in
size. The 'partition-number' furnished by pdisk is 6. The only thing
in this partition is a 2KB text file.
WD-OrigBack is the partition which will hold the backup. The partition
number furnished by pdisk is 7.
Both partitions are UFS partitions.
I 'unmounted' both partitions.
My dump command:
sudo dump -0u -s 1 -f /dev/disk1s7 /dev/disk1s6
The dump went normally, no errors. According to the printout, the dump
produced 2.25 tape "volumes", even though my backup was to a partition,
not a tape.
Now I tried to restore -
Verified both partitions were still 'unmounted', then I issued the
following commands:
sudo newfs /dev/disk1s6
mkdir /mnt
sudo mount /dev/disk1s6 /mnt
cd /mnt
sudo restore -r -f /dev/disk1s7
Error message:
"Tape is not volume 1 of the dump"
I don't know how to supply restore with the necessary information.
man pages and books give no clue as to what is going on.
FWIW, I created a successful dump *and* restore when I removed "-s 1"
from the dump command, however the exact same error message comes up
when I try to restore a 2GB OSX UFS partition using this exact same
method (minus the "-s 1" in the dump command) - - - and 23 'tape
volumes' are produced by dump.
Mark-
Tom Stiller
Mark Conrad <nos...@iam.invalid> wrote:
> Looking for help using the dump/restore commands in Mac OSX Terminal.
>
[snip]
>
> My dump command:
>
> sudo dump -0u -s 1 -f /dev/disk1s7 /dev/disk1s6
>
> The dump went normally, no errors. According to the printout, the dump
> produced 2.25 tape "volumes", even though my backup was to a partition,
> not a tape.
Because you told dump you had a 1 foot of dump media at the default
density of 1600 BPI. Also, you did not specify the output device as a
"raw" device. I don't know what dump does about labels in such a case.
>
> Now I tried to restore -
>
[snip]
>
> sudo restore -r -f /dev/disk1s7
>
> Error message:
>
> "Tape is not volume 1 of the dump"
>
> I don't know how to supply restore with the necessary information.
>
> man pages and books give no clue as to what is going on.
>
> FWIW, I created a successful dump *and* restore when I removed "-s 1"
> from the dump command, however the exact same error message comes up
> when I try to restore a 2GB OSX UFS partition using this exact same
> method (minus the "-s 1" in the dump command) - - - and 23 'tape
> volumes' are produced by dump.
That, and reading the man page, should have given you a clue as to why
the earlier dump failed.
Try specifyint the output device as either a raw disk partition or a
file or as a file name on a valid filesystem partition.
--
Tom Stiller
PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3 7BDA 71ED 6496 99C0 C7CF
Mark Conrad
<tomstiller-D8536...@news.comcast.giganews.com>, Tom
Stiller <tomst...@comcast.net> wrote:
> > My dump command:
> >
> > sudo dump -0u -s 1 -f /dev/disk1s7 /dev/disk1s6
> >
> > The dump went normally, no errors. According to the printout, the dump
> > produced 2.25 tape "volumes", even though my backup was to a partition,
> > not a tape.
>
> Because you told dump you had a 1 foot of dump media at the default
> density of 1600 BPI. Also, you did not specify the output device as a
> "raw" device. I don't know what dump does about labels in such a case.
Pertaining to the "raw" device issue - I assumed "/dev/disk1s7" _was_
specifying the output device as a "raw" device.
Isn't a partition that gets completely overwritten a raw device?
(even the file-system on the "/dev/disk1s7" partition gets overwritten,
more or less establishing that the partition was properly designated as
a "raw" partition, I reasoned)
Perhaps I don't understand how to specify a "raw" partition?
> Try specifying the output device as ...<snipped>... or a
> file or as a file name on a valid filesystem partition.
I did, but the error message still occured - probably because stuff is
getting munged up due to me not knowing how to specify a "raw" device.
I even tried altering the dump command away from the default tape
length of 2300 feet, to a very large value of 300000 feet, so only
_one_ tape volume would be produced, but got an error message about
illegal tape length.
I can only get the dump/restore to work properly on very small-content
partitions, where only one "tape volume" is produced, at the default
tape length of 2300 feet. (or less, as specified by the "-s" option)
For example, I succeeded in backing up and restoring a small UFS
partition whose only contents were a 2KB text file, even though I was
using the option "-s 1" in the dump command - - - the backup succeeded
because only _one_ "tape volume" was created, so later the "restore"
command could not possibly get confused about which-number tape was
being pointed to and spit out the 'usual' error message:
"Tape is not volume 1 of the dump"
Mark-
PS - thanks for trying to help, eventually I will not be such a royal
PITA when I somehow manage to get more Unix under my belt.
Tom Stiller
Mark Conrad <nos...@iam.invalid> wrote:
> In article
> <tomstiller-D8536...@news.comcast.giganews.com>, Tom
> Stiller <tomst...@comcast.net> wrote:
>
> > > My dump command:
> > >
> > > sudo dump -0u -s 1 -f /dev/disk1s7 /dev/disk1s6
> > >
> > > The dump went normally, no errors. According to the printout, the dump
> > > produced 2.25 tape "volumes", even though my backup was to a partition,
> > > not a tape.
> >
> > Because you told dump you had a 1 foot of dump media at the default
> > density of 1600 BPI. Also, you did not specify the output device as a
> > "raw" device. I don't know what dump does about labels in such a case.
>
> Pertaining to the "raw" device issue - I assumed "/dev/disk1s7" _was_
> specifying the output device as a "raw" device.
You were told many posts ago in a thread far away that prefixing the
device name with the character "r" converted the reference to a "raw"
device (e.g. /dev/rdisk1s7).
>
[snip]
>
> Perhaps I don't understand how to specify a "raw" partition?
That's just a small part of what you don't understand. I've asked you
before to take time to understand the fundamental interaction between
device and files; until you do, you're in for a ton of frustration while
playing with low-level tools.
[snip]
>
> PS - thanks for trying to help, eventually I will not be such a royal
> PITA when I somehow manage to get more Unix under my belt.
You _do_ need to stop examining the bark of each tree and try to get a
picture of the forest.
Mark Conrad
<tomstiller-481C1...@news.comcast.giganews.com>, Tom
Stiller <tomst...@comcast.net> wrote:
> > Pertaining to the "raw" device issue - I assumed "/dev/disk1s7" _was_
> > specifying the output device as a "raw" device.
>
> ... prefixing the device name with the character "r" converted the reference
> to a "raw" device (e.g. /dev/rdisk1s7).
I am having a very hard time getting hold of any Unix docs that explain
the difference between "disk" and "rdisk".
To my way of thinking, because dump, dd, etc. can overwrite the file
system on a partition when "/dev/disk1s7" is used, then that implies
that the shell commands are writing directly to the raw disk, ignoring
and overwriting any file system that is on the disk partition.
I guess Unix has a different explanation, from what you write.
Here is the copy-and-paste results from my Terminal window, after I
switched from "disk" to "rdisk"
Start of Terminal Window Printout -
####################################
Last login: Sat Feb 1 23:13:35 on ttyp1
Welcome to Darwin!
[Mark-Conrads-Computer:~] mark% sudo pdisk /dev/disk1 -dump
/dev/disk1 map block size=512
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: Apple_UFS WD-Jag 4176896 @ 64 ( 2.0G)
3: Apple_UFS WD-JagBackup 4299168 @ 4176960 ( 2.1G)
4: Apple_UFS WD-Original 104864 @ 8476128 ( 51.2M)
5: Apple_UFS WD-OrigBackup 125840 @ 8580992 ( 61.4M)
6: Apple_UFS WD-Storage 51367944 @ 8706832 ( 24.5G)
7: Apple_Free 0+@ 60074776
Device block size=512, Number of Blocks=60074784
DeviceType=0x0, DeviceId=0x0
[Mark-Conrads-Computer:~] mark% sudo dump -0u -s 1 -f /dev/rdisk1s5
/dev/rdisk1s4
DUMP: Date of this level 0 dump: Sat Feb 1 23:22:51 2003
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdisk1s4 to /dev/rdisk1s5
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 53 tape blocks on 2.01 tape(s).
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: Closing /dev/rdisk1s5
DUMP: Change Volumes: Mount volume #2
DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") y
DUMP: Volume 2 begins with blocks from inode 3
DUMP: Closing /dev/rdisk1s5
DUMP: Change Volumes: Mount volume #3
DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") y
DUMP: Volume 3 begins with blocks from inode 993
DUMP: DUMP: 44 tape blocks on 3 volumes(s)
DUMP: level 0 dump on Sat Feb 1 23:22:51 2003
DUMP: Closing /dev/rdisk1s5
DUMP: DUMP IS DONE
[Mark-Conrads-Computer:~] mark% sudo newfs /dev/rdisk1s4
newfs: disk1s4 is mounted on /Volumes/WD-Original
[Mark-Conrads-Computer:~] mark% mkdir /mnt
mkdir: /mnt: File exists
[Mark-Conrads-Computer:~] mark% sudo mount /dev/rdisk1s4 /mnt
/dev/rdisk1s4 on /mnt: Block device required
[Mark-Conrads-Computer:~] mark% cd /mnt
[Mark-Conrads-Computer:/mnt] mark% sudo restore -r -f /dev/rdisk1s5
Tape is not volume 1 of the dump
[Mark-Conrads-Computer:/mnt] mark%
#######################################
End of Terminal Window Copy-and-Paste -
As you can see, the error message "Tape is not volume 1 of the dump"
occured again, despite my using "rdisk" throughout.
I next tried only using "rdisk" for the one partition _only_ , the
partition that stores the backup, "/dev/rdisk1s5" in this case:
Start of Terminal Window Printout -
####################################
[Mark-Conrads-Computer:~] mark% sudo dump -0u -s 1 -f /dev/rdisk1s5
/dev/disk1s4
DUMP: Date of this level 0 dump: Sat Feb 1 23:57:46 2003
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/disk1s4 to /dev/rdisk1s5
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 53 tape blocks on 2.01 tape(s).
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: Closing /dev/rdisk1s5
DUMP: Change Volumes: Mount volume #2
DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") y
DUMP: Volume 2 begins with blocks from inode 3
DUMP: Closing /dev/rdisk1s5
DUMP: Change Volumes: Mount volume #3
DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") y
DUMP: Volume 3 begins with blocks from inode 993
DUMP: DUMP: 44 tape blocks on 3 volumes(s)
DUMP: level 0 dump on Sat Feb 1 23:57:46 2003
DUMP: Closing /dev/rdisk1s5
DUMP: DUMP IS DONE
[Mark-Conrads-Computer:~] mark% sudo newfs /dev/disk1s4
Warning: 96 sector(s) in last cylinder unallocated
disk1s4: 104864 sectors in 205 cylinders of 16 tracks, 32 sectors
51.2MB in 13 cyl groups (16 c/g, 4.00MB/g, 992 i/g)
super-block backups (for fsck -b #) at:
32, 8256, 16480, 24704, 32928, 41152, 49376, 57600,
65824, 74048, 82272, 90496, 98720,
[Mark-Conrads-Computer:~] mark% mkdir /mnt
[Mark-Conrads-Computer:~] mark% sudo mount /dev/disk1s4 /mnt
[Mark-Conrads-Computer:~] mark% cd /mnt
[Mark-Conrads-Computer:/mnt] mark% sudo restore -r -f /dev/rdisk1s5
Tape is not volume 1 of the dump
[Mark-Conrads-Computer:/mnt] mark%
#######################################
End of Terminal Window Printout -
As you can see, the error message "Tape is not volume 1 of the dump"
occured again, the only 'improvement' was that the error message
following the line "sudo mount....." - - -
"/dev/rdisk1s4 on /mnt: Block device required" <---error msg
.....did not occur this time
Mark-
Mark Conrad
<jdoh...@null.com> wrote:
> > Pertaining to the "raw" device issue - I assumed "/dev/disk1s7" _was_
> > specifying the output device as a "raw" device.
>
> The raw device would be /dev/rdisk1s7.
Thanks, it is far from clear in my mind when to use the two forms.
> > I even tried altering the dump command away from the default tape
> > length of 2300 feet, to a very large value of 300000 feet, so only
> > _one_ tape volume would be produced, but got an error message about
> > illegal tape length.
>
> Look into the "-a" option to dump.
Thanks again, I will try that.
Mark-
Tony Lawrence
> Isn't a partition that gets completely overwritten a raw device?
No. "Raw" has two meanings, depending on the context. In the first
sense, we're talking about the access method, which entry in /dev/ is
used. Block devices will show "b" as the first character of their perms
and character or raw devices have "c". Raw disk devices often have "r"
as the first character of their name. A block device gets a buffer
allocated, a raw device doesn't. It can get a little confusing because
some devices (a terminal) would only have a character device, while
things like disk drives would have both. See
http://aplawrence.com/Bofcusm/321.html for more on that.
In the second sense, people will sometimes use a partition without a
file system for database storage. That's a "raw partition"; the
database accesses it directly without the overhead of a file system.
--
Tony Lawrence
Free SCO, Mac OS X and Linux Skills Tests:
http://aplawrence.com/skillstest.html
Tony Lawrence
> In article <jdoherty-010...@192.168.2.178>, John Doherty
> <jdoh...@null.com> wrote:
>
>
>>>Pertaining to the "raw" device issue - I assumed "/dev/disk1s7" _was_
>>>specifying the output device as a "raw" device.
>>
>>The raw device would be /dev/rdisk1s7.
>
>
> Thanks, it is far from clear in my mind when to use the two forms.
It's far from clear in most people's minds :-)
As I explained in a previous post, the block device is buffered, and the
character device is not. Which one you use *sometimes* makes sense
(you'd mount a block disk device, you'd write to a raw tape device), but
sometimes gets clouded because an operation that you'de be certain would
be block oriented isn't, or even if it is the command will happily
accept a character device as its target and will translate that itself
because it knows better :-)
Jeremy
> I am trying to do a level zero dump and restore of a UFS volume on an
> external drive.
I seriously think you need to re-examine why you want to do this. Whatever
it is you're trying to accomplish, I can't imagine that "dump" is the best
way to get there.
--
Jeremy | jer...@exit109.com
Tom Stiller
Mark Conrad <nos...@iam.invalid> wrote:
> Here is the copy-and-paste results from my Terminal window, after I
> switched from "disk" to "rdisk"
And here, for the last time, is a complete example for you. This time,
of a dump and restore operation. This by the way, is exactly what I
meant by my earlier comment about helping you being an inordinate amount
of work.
I don't use dump/restore and never will. This example was executed with
the man pages open in front of me so I could see which parameters were
needed and what they did.
Please take the time to study the complete example. If you don't
understand something, refer to the man pages with an appreciation for
what the command is supposed to do and the knowledge that it does
accomplish its purpose.
------------------------------------------------------------------------
Dump the UFS partition:
[imac:~tms] root# dump -0u -f test_dump /dev/rdisk1s4
DUMP: Date of this level 0 dump: Sun Feb 2 07:11:54 2003
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdisk1s4 to test_dump
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 1679 tape blocks on 0.04 tape(s).
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: DUMP: 1677 tape blocks on 1 volumes(s)
DUMP: level 0 dump on Sun Feb 2 07:11:54 2003
DUMP: Closing test_dump
DUMP: DUMP IS DONE
Unmount the device:
[imac:~tms] root# hdiutil unmount /Volumes/untitled/
"disk1s4" unmounted successfully.
Create a new filesystem, destroying the old contents:
[imac:~tms] root# newfs /dev/rdisk1s4
Warning: 64 sector(s) in last cylinder unallocated
disk1s4: 3520 sectors in 7 cylinders of 16 tracks, 32 sectors
1.7MB in 1 cyl groups (16 c/g, 4.00MB/g, 448 i/g)
super-block backups (for fsck -b #) at:
32,
Mount the volume:
[imac:~tms] root# hdiutil mountvol /dev/disk1s4
/dev/disk1s4 Apple_UFS /Volumes/untitled
[imac:~tms] root# ls -l /Volumes/untitled/
total 2
d-wx-wx-wx 3 root wheel 1024 Feb 2 07:13 .Trashes
Change working directory:
[imac:~tms] root# pushd /Volumes/untitled/
/Volumes/untitled ~tms
[imac:/Volumes/untitled] root# restore -rf ~tms/test_dump
warning: ./.Trashes: File exists
warning: ./.Trashes/501: File exists
Display the results of the restore:
[imac:/Volumes/untitled] root# ls
.Trashes IMG_1164.JPG IMG_1295.JPG
LATA_Map.gif bushandclippy.jpeg restoresymtable
Display the volume data (it's not a very big partition):
[imac:/Volumes/untitled] root# df /Volumes/untitled/
Filesystem 512-blocks Used Avail Capacity Mounted on
/dev/disk1s4 3350 3342 -158 104% /Volumes/untitled
------------------------------------------------------------------------
Mark Conrad
<tomstiller-44E3D...@news.comcast.giganews.com>, Tom
Stiller <tomst...@comcast.net> wrote:
> And here, for the last time, is a complete example for you.
- - and - -
> (it's not a very big partition)
Thanks. I have reservations about whether your example will work on a
larger partition, where more than one "tape volume" is created by dump.
I have no trouble backing up and restoring small partitions, as I
mentioned in previous posts in this thread:
Mark Conrad posted previously:
> For example, I succeeded in backing up and restoring a small UFS
> partition whose only contents were a 2KB text file, even though I was
> using the option "-s 1" in the dump command - - - the backup succeeded
> because only _one_ "tape volume" was created, so later the "restore"
> command could not possibly get confused about which-number tape was
> being pointed to...
- - -and - - -
> FWIW, I created a successful dump *and* restore when I removed "-s 1"
> from the dump command, however the exact same error message comes up
> when I try to restore a 2GB OSX UFS partition using this exact same
> method (minus the "-s 1" in the dump command) - - - and 23 'tape
> volumes' are produced by dump.
Tom Stiller observed:
> This by the way, is exactly what I meant by my earlier comment about
> helping you being an inordinate amount of work.
By all means, cease helping whenever that occurs! - - - I have no
intention of working a hardship on anyone.
> Please take the time to study the complete example.
I intend to. As usual your posts are a gold mine of useful
information.
> If you don't understand something, refer to the man pages with an
> appreciation for what the command is supposed to do and the
> knowledge that it does accomplish its purpose.
I have seldom solved any of my problems here by refering to the man
pages for help. As others have said, those pages are intended for
someone who already knows how the stuff works, and just serves to jog
their memory about details they may have forgotten.
Also, the "usual" Unix/Linux books I had access to in the past did not
help much.
If there is such a thing as a "complete" and "up-to-date" Unix book, I
sure would appreciate knowing about it - - - hopefully, a book that
could be applied directly to Apple's OSX version of Unix.
Mark-
Mark Conrad
<to...@pcunix.com> wrote:
> > Thanks, it is far from clear in my mind when to use the two forms.
>
> It's far from clear in most people's minds :-)
Your two posts concerning "rdisk" vs "disk" helped me considerably to
understand those two forms.
I guess what it boils down to is that _some_ organization using
"rdisk" and "disk" is better than no organization at all, despite the
difficulty learning how/when to use the proper version.
Gadd! - I hope there is not _too_ much more ambiguous stuff like that
in Unix.
Mark-
Mark Conrad
<jer...@exit109.com> wrote:
> > I am trying to do a level zero dump and restore of a UFS volume on an
> > external drive.
>
> I seriously think you need to re-examine why you want to do this. Whatever
> it is you're trying to accomplish, I can't imagine that "dump" is the best
> way to get there.
Occassionally, I need to expand the size of my Mac OSX UFS partition.
Whenever that happens, I have to reload OSX from scratch, reload all my
3rd-party applications, and reconfigure all the settings.
Backup app's like Retrospect won't work on UFS partitions.
Backups made using Terminal's dd won't work on an 'expanded' UFS
partition either, for various reasons.
I am going to try the dump/restore combination, to see if that will
work. (possibly with a little juggling of the "Partition_map"
partition)
I hope dump/restore will act something like "Retrospect-for-UFS".
Mark-
Jeremy
>>> I am trying to do a level zero dump and restore of a UFS volume on an
>>> external drive.
>>
>> I seriously think you need to re-examine why you want to do this. Whatever
>> it is you're trying to accomplish, I can't imagine that "dump" is the best
>> way to get there.
>
> Occassionally, I need to expand the size of my Mac OSX UFS partition.
>
> Whenever that happens, I have to reload OSX from scratch, reload all my
> 3rd-party applications, and reconfigure all the settings.
>
> Backup app's like Retrospect won't work on UFS partitions.
>
> Backups made using Terminal's dd won't work on an 'expanded' UFS
> partition either, for various reasons.
Okay, I would recommend that you use pax, or tar (pax is a bit more sane,
and creates by default the same archive format as tar). It will have the
same result as a successful use of dump. It probably can't create a
bootable volume on restore, but if it can't, dump can't either. It won't
work on HFS+ volumes, but neither with dump.
You don't want to back up to a raw disk device; just create a backup file
on a filesystem on the external drive.
Something like this ought to create a backup of an entire directory
hierarchy, without straying from the single disk it's on:
cd /root
pax -w -X -f /path/to/backup.tar .
...where backup.tar is the name of the backup file to create, in the
directory specified; and /root is the top of the hierarchy you want to
back up. You'd use / to specify the top-level system directory. The
-X option keeps it from going onto other disks.
Restore it with:
cd /root
pax -r -f /path/to/backup.tar -p e
...where /root is the top level where you want the backup restored. Run
both of these as the superuser.
> I am going to try the dump/restore combination, to see if that will
> work. (possibly with a little juggling of the "Partition_map"
> partition)
>
> I hope dump/restore will act something like "Retrospect-for-UFS".
I think you're under the impression that dump creates a backup of the
device; that's not the case. It works with files. It doesn't create
an exact duplicate of a whole disk, it only backs up filesystems.
If you want to create a duplicate of a disk device, dd is what you want,
but you've already discovered that it really doesn't work the way you
want. The unfortunate case here is that what you want to do isn't
something people often want to do on Unix, so the common software Unix
geeks use to make backups simply isn't going to do what you want no
matter how hard you try. In my whole Unix career I have never made a
complete backup of a disk device, nor had occasion to want to.
I would recommend that you abandon the idea of UFS -- there really is no
good reason to use it on OS X unless you're running something that needs
a case-sensitive filesystem, and then, it's best to just make a small UFS
for that. There are good reasons *not* to use UFS with OS X, though, one
of which is that Apple's implementation is significantly slower than
HFS+.
If you use HFS+, you might find a backup program which works the way you
want, since exact copies of disks are something personal-computer users
want a lot more than Unix geeks. If Retrospect does what you want (I have
no knowledge or experience of it) then that's probably your best bet.
But if I'm right that you're looking to create a complete backup of a disk
device, then stop playing with dump right now, because you're only wasting
your time.
--
Jeremy | jer...@exit109.com
Mark Conrad
> > I even tried altering the dump command away from the default tape
> > length of 2300 feet, to a very large value of 300000 feet, so only
> > _one_ tape volume would be produced, but got an error message about
> > illegal tape length.
>
> Look into the "-a" option to dump.
I could not find any "a" option for dump in my Mac OSX man pages.
Hmm, I wonder if it is usable even though it is not listed.
In any case, without documentation on how to use it, I am dead.
Mark-
Mark Conrad
<jer...@exit109.com> wrote:
> But if I'm right that you're looking to create a complete backup of a disk
> device, then stop playing with dump right now, because you're only wasting
> your time.
Ah, lemme play a little longer ;-)
> > I hope dump/restore will act something like "Retrospect-for-UFS".
>
> I think you're under the impression that dump creates a backup of the
> device; that's not the case. It works with files. It doesn't create
> an exact duplicate of a whole disk...<clipped>...
I am aware of that, dump will not back up an entire disk, for example
it will not back up the Driver_descriptor_map (absolute disk sector
zero)
dump will back up individual UFS partitions, on a file-by-file basis,
the same as Retrospect does for HFS+ partitions.
As for whether dump is capable of creating a bootable UFS partition, I
will have to find that out by experimenting with it.
Each bootable UFS partition has satellite partitions associated with
it, the "Booter" and "Loader" partitions, plus a "Partition map"
partition which is common to all bootable UFS partitions on disk.
I can backup all these partitions with dump, and probably pax, once I
learn how to properly use them. (dump and pax, that is)
If the various UFS machine code "pointers" get messed up by me moving
all the file-by-file backups to a much larger partition, as I want to
do, the resulting restored partitions will not be bootable.
In that case I will abandon my dump/restore plans, because I need
bootable partitions.
A quick look at the man page for pax tells me that it could be as hard
to learn as dump/restore, possibly harder.
> I would recommend that you abandon the idea of UFS...
Naw, I run both UFS and HFS+ on the same computer (Pismo-powerbook with
1,024MBs of installed ram) - - - small external disk for UFS.
I am intrigued with the idea of plopping Unix applications onto the UFS
hard-drive and being more-or-less assured that they will run.
...not always the case when installing the same app's onto a HFS+
partition.
Jeremy
> If the various UFS machine code "pointers" get messed up by me moving
> all the file-by-file backups to a much larger partition, as I want to
> do, the resulting restored partitions will not be bootable.
>
> In that case I will abandon my dump/restore plans, because I need
> bootable partitions.
You're backing up files, so there aren't any issues with UFS pointers.
You can back up every file on the disk, but the restored volume won't
be bootable. I'm not even entirely sure how to do that manually, but
you might want to look at "bless".
> A quick look at the man page for pax tells me that it could be as hard
> to learn as dump/restore, possibly harder.
Far easier. Follow my examples. Ignore the options in the man page that
weren't in my examples. You don't need to care about the archive format
or block sizes or file selection criteria, so don't get distracted by
that stuff. My examples are all you need to get started and make full
backups (of filesystems, not devices).
> I am intrigued with the idea of plopping Unix applications onto the UFS
> hard-drive and being more-or-less assured that they will run.
>
> ...not always the case when installing the same app's onto a HFS+
> partition.
Such problems are vanishingly rare.
--
Jeremy | jer...@exit109.com
Mark Conrad
<jer...@exit109.com> wrote:
> > A quick look at the man page for pax tells me that it could be as hard
> > to learn as dump/restore, possibly harder.
>
> Far easier. Follow my examples.
Okay, and thanks.
Should be a lot of fun :)
> > If the various UFS machine code "pointers" get messed up by me moving
> > all the file-by-file backups to a much larger partition, as I want to
> > do, the resulting restored partitions will not be bootable.
>
> You're backing up files, so there aren't any issues with UFS pointers.
I am kinda hazy about this, but I was thinking about the pointers in
the "Partition-map" partition, absolute disk sectors 1-63
I think that special partition, which does not ordinarily get backed up
by the usual Unix backup schemes, holds pointers to every UFS partition
on disk, pointing to where the individual UFS partitions start, and
where they end.
With any luck, the restored (critical) file-system files will be
plopped back into the same exact physical places on disk that they
originally came from.
With no luck, the critical file-system files will be placed in a
slightly different spot, a spot "not-pointed-to" by the pointers in the
partition_map, which could render the UFS partition un-bootable.
Of course my reasoning could be all wet, I am no programmer.
That is one reason I prefer "mirror" backups of OSX UFS partitions as
produced by dd - - - they are more-or-less guaranteed to be bootable.
Unfortunately 'mirror' backups can't be transfered to a larger
partition without bad things happening, which is why I need a
file-by-file backup scheme like pax or dump.
Anyone wanna guess whether a file-by-file backup produced by pax or
dump would be bootable.
I dunno, which is why I am experimenting with them.
Mark-
Tony Lawrence
The way to make a bootable backup set would be to create a bootable and
mountable filesystem first (I think you've already done that?) and then,
when you want to backup, mount it and use something like
cd /
find . | cpio -pdmv /Volumes/Mybackup
to freshen the files on it.
Jeremy
> I think that special partition, which does not ordinarily get backed up
> by the usual Unix backup schemes, holds pointers to every UFS partition
> on disk, pointing to where the individual UFS partitions start, and
> where they end.
>
> With any luck, the restored (critical) file-system files will be
> plopped back into the same exact physical places on disk that they
> originally came from.
>
> With no luck, the critical file-system files will be placed in a
> slightly different spot, a spot "not-pointed-to" by the pointers in the
> partition_map, which could render the UFS partition un-bootable.
You're thinking too much.
The UFS partition is a filesystem. A restored file backup will be new
files, on a new filesystem, with exactly the same data. It's not a
mirror image at the disk level. This doesn't matter.
> Anyone wanna guess whether a file-by-file backup produced by pax or
> dump would be bootable.
On its own, it wouldn't be.
My guess is that you can make it so. Have you looked at "bless" as I
suggested? I've never used it, but it claims to make things bootable.
However, it looks as though it might make your brain explode, so don't
say I didn't warn you.
--
Jeremy | jer...@exit109.com
Mark Conrad
<jer...@exit109.com> wrote:
> > Anyone wanna guess whether a file-by-file backup produced by pax or
> > dump would be bootable.
>
> On its own, it wouldn't be.
>
> My guess is that you can make it so. Have you looked at "bless" as I
> suggested?
Yep, it is definitely geared towards HFS+ file-systems only, not UFS.
Tony Lawrence suggested the Unix command "cpio", to actually alter the
backup file itself, in order to make the backup file "compatable" with
a fresh blank OSX UFS partition, one that contained _only_ the Mac
OSX installed into a UFS partition.
The idea is that cpio would modify the backup file itself, *then*
copy the modified backup file into the 'blank' OSX partition.
Hopefully, it would then be both bootable, and _also_ contain all the
personal backed-up files, their correct permissions, configurations,
etc.
Tony's example code:
cd /
find . | cpio -pdmv /Volumes/Mybackup
cpio itself looks pretty ferocious, and I would guess if one was not
100% familiar with how to use all the options, the resulting restored
backup might not be exactly "correct".
Mark-
Mark Conrad
<to...@pcunix.com> wrote:
> The way to make a bootable backup set would be to create a bootable and
> mountable filesystem first (I think you've already done that?) and then,
> when you want to backup, mount it and use something like
>
> cd /
> find . | cpio -pdmv /Volumes/Mybackup
>
> to freshen the files on it.
Yep, I have no problem creating a "blank" bootable and mountable OSX
UFS filesystem, containing "only" Apple's OSX 'inside' a UFS partition.
I did not know Unix had the sort of commands that could "freshen"
<modify> the backed-up partition itself, such that it would be
'compatable' with the file-system data in a 'blank' bootable OSX UFS
partition.
.....commands like "cpio", that is.
I assumed that the "find" command is not really necessary, but is there
to display what changes were made by the "cpio" command.
I would give my eye teeth to get hold of good Unix books which go into
great detail about all the 900 various Unix shell commands,
applications, etc. with great detail about _all_ the options,
arguments, etc. - describing what those options actually do in plain
language, without resorting to the confusing mumbo-jumbo used in the
man pages, said mumbo-jumbo assuming a 5 year Unix background with how
all the terminology is used.
It would also be nice to have _extensive_ command-line examples of
exactly how _all_ the command-line options can be used to accomplish
specific tasks, instead of the hit or miss examples one usually sees.
No doubt there are old 5,000 page books around that come close to doing
that, but I doubt if there are modern detailed Unix books.
Guess Unix has to be learned the hard, slow, difficult way.<g>
...unless of course one has thousands of dollars to spend on personal
instructors, coupled with a *reason* to become adept at Unix, coupled
with years of time to learn it. (and a darn good memory)
I would settle for good books. :)
Mark-
P.S. - I filed your code example for using cpio will try it out in the
next couple of days, thanks very much.
Mark Conrad
<to...@pcunix.com> wrote:
> The way to make a bootable backup set would be to create a bootable and
> mountable filesystem first (I think you've already done that?) and then,
> when you want to backup, mount it and use something like
>
> cd /
> find . | cpio -pdmv /Volumes/Mybackup
>
> to freshen the files on it.
Whoops! - sorry, forgot to ask about one point.
How is the modified "Mybackup" file steered towards the "bootable and
mountable" filesystem? I did not see that in your example code.
Granted that I "cd /", but there may be _several_ OSX partitions on
the desktop, what steers the modified 'Mybackup' to the correct
partition?
Thanks,
Mark-
Tony Lawrence
I forgot to mention that cpio probably isn't aware of Mac resource forks
either..
It isn't ferocious though..
Tony Lawrence
> I did not know Unix had the sort of commands that could "freshen"
> <modify> the backed-up partition itself, such that it would be
> 'compatable' with the file-system data in a 'blank' bootable OSX UFS
> partition.
>
> .....commands like "cpio", that is.
>
> I assumed that the "find" command is not really necessary, but is there
> to display what changes were made by the "cpio" command.
No, it's there to tell cpio what to back up.
>
> I would give my eye teeth to get hold of good Unix books which go into
> great detail about all the 900 various Unix shell commands,
> applications, etc. with great detail about _all_ the options,
> arguments, etc. - describing what those options actually do in plain
> language, without resorting to the confusing mumbo-jumbo used in the
> man pages, said mumbo-jumbo assuming a 5 year Unix background with how
> all the terminology is used.
Oh come on. That would be a 60 volume encyclopedia. It would be
horrendously expensive, take up too much shelf space, and you'd never
use 99% of it.
Gaad. I have many thousands of dollars worth of books here. I figure
about $300.00 per foot of shelf space, and I have about 40 feet
dedicated to computer related books. Even all that doesn't begin to
have what you ask for.
>
> It would also be nice to have _extensive_ command-line examples of
> exactly how _all_ the command-line options can be used to accomplish
> specific tasks, instead of the hit or miss examples one usually sees.
Yeah, right. Another 20 volumes just for that :-)
>
> No doubt there are old 5,000 page books around that come close to doing
> that, but I doubt if there are modern detailed Unix books.
>
> Guess Unix has to be learned the hard, slow, difficult way.<g>
>
> ...unless of course one has thousands of dollars to spend on personal
> instructors, coupled with a *reason* to become adept at Unix, coupled
> with years of time to learn it. (and a darn good memory)
>
> I would settle for good books. :)
>
I have reviewed and recommended a number of Unix books at
http://aplawrence.com/Books. You know enough about my background from
reading here to know whether or not you might agree with my tastes, but
in case it isn't obvious, I admire techy books that don't assume too
much prior knowledge but also don't waste time with the truly trivial.
Tony Lawrence
Sorry - too much simplification.
First: I assumed that /Volumes/Mybackup is the target.
Second, the "find" would need modification to exclude that. How to best
do that depends on the capabilities of find, which vary from Unix to
Unix, but if there's no better way you can do something like
find / | sed "/\/Volumes\/Mybackup/d;/OtherdirIdon'tWantToBackup/d" |
cpio /Volumes/Mybackup
Many finds have options that restrict it to the current filesystem, etc.
Tony Lawrence
> I would give my eye teeth to get hold of good Unix books which go into
> great detail about all the 900 various Unix shell commands,
> applications, etc. with great detail about _all_ the options,
> arguments, etc. - describing what those options actually do in plain
> language, without resorting to the confusing mumbo-jumbo used in the
> man pages, said mumbo-jumbo assuming a 5 year Unix background with how
> all the terminology is used.
As I've said elsewhere, that's a large, expensive encyclopedia that you
wouldn't use 99% of.
Here are some slightly smaller, though still rather hefty, Unix books.
As you will see, I don't care for some of them, and NONE of them are
specific to Mac OS X:
http://pcunix.com/Books/unixunleashed.html
http://pcunix.com/Books/unixcompref.html
http://pcunix.com/Books/impatient.html
http://pcunix.com/Books/essentialunix.html
If you owned every single book I own (and that's a lot of books), you
STILL wouldn't have what you ask for.
I also have some Mac OS X books:
http://pcunix.com/Books/macosxunixgeeks.html
http://pcunix.com/Books/macosx.html
http://pcunix.com/Books/macosxdisaster.html
Which may be good to have but again are not the encyclopedia you
mistakenly think you want.
Tom Stiller
Tony Lawrence <to...@pcunix.com> wrote:
> Mark Conrad wrote:
> > In article <10442881...@ok-corral.gunslinger.net>, Jeremy
> > <jer...@exit109.com> wrote:
> >
[snip]
> >
> > cpio itself looks pretty ferocious, and I would guess if one was not
> > 100% familiar with how to use all the options, the resulting restored
> > backup might not be exactly "correct".
>
> I forgot to mention that cpio probably isn't aware of Mac resource forks
> either..
No, but hfspax is aware of resource forks and will backup in the cpio
format.
>
>
> It isn't ferocious though..
--
Tony Lawrence
> In article <w6N%9.160599$VU6.1...@rwcrnsc52.ops.asp.att.net>,
> Tony Lawrence <to...@pcunix.com> wrote:
>>
>>I forgot to mention that cpio probably isn't aware of Mac resource forks
>>either..
>
>
> No, but hfspax is aware of resource forks and will backup in the cpio
> format.
And where do we find hfspax?
Ernie Klein
Mark Conrad <nos...@iam.invalid> wrote:
>
> Tony's example code:
>
> cd /
> find . | cpio -pdmv /Volumes/Mybackup
>
>
> cpio itself looks pretty ferocious, and I would guess if one was not
> 100% familiar with how to use all the options, the resulting restored
> backup might not be exactly "correct".
>
> Mark-
As I said once before, in jest, (in another thread I think) that if you
ask 10 Unix guru's how to perform a task, you may get 10 different
answers, all of which are correct.
That is because there are many, many Unix commands that overlap and
preform the same task. Many commands were written at different times by
different people. Some programmers added an options to a command that
did essentially the same job as another command, but more efficiently.
Some commands had their origins in various implementations of Unix.
Some came from the original ATT, Bell labs version, other came from
other versions. I grew up, so to speak, with 'od' (octal dump), others
like the newer 'hexdump', they are simular but not the same. In most
cases either can be used, it is a personal preference which to use.
Many commands are that way. In a way, Unix is much like language, and
when used in scripts, I guess it is a programing language of sorts.
Just as a sentence can be constructed differently by different people,
using different words to say the same thing; different Unix commands can
be strung together by different people to accomplish the same task. But
just like english, one must learn the vocabulary, usually starting with
simple words and construction, before one gets to the more difficult
ones.
When you start combining commands as Tony did in his example, he
introduced an entirely new Unix concept to you; pipes. The '|' is a
pipe. That means that the find command, instead of producing an output
that goes to a file or terminal, 'pipes' its output directly to the
input of the archiving command cpio. The ability to combine commands
(pipe) in one of the things that make Unix so powerful. There are
almost limitless ways of combining commands, using various options to
each command, to preform a given task. Rarely will two Unix 'guru's'
choose the same commands and options, but the end result will be the
same. That is one reason you get so many 'different' answers to some of
your questions.
-Ernie-
Mark Conrad
Ernie Klein <eckleins...@pacbell.net> wrote:
> > 100% familiar with how to use all the options, the resulting restored
> > backup might not be exactly "correct".
> >
> > Mark-
>
> As I said once before, in jest, (in another thread I think) that if you
> ask 10 Unix guru's how to perform a task, you may get 10 different
> answers, all of which are correct.
Wow, there certainly is a lot of help in this NG for Mac newbies like
me. Beats the Unix books all to heck.<g>
Now I am worried about "payback". I am building up a helluva debt
here, doing a lotta 'taking' and not contributing anything.
It is starting to give me a giant sized guilty conscience.
I can't even "advise" those Mac users who know less that I do, because
right now the advice I dispense would likely be wrong.
Anyhow, back to your post, a very fine one for a newbie.
(gonna file it so I can dispense it later to other Mac newbies)
> When you start combining commands as Tony did in his example, he
> introduced an entirely new Unix concept to you; pipes. The '|' is a
> pipe. That means that the find command, instead of producing an output
> that goes to a file or terminal, 'pipes' its output directly to the
> input of the archiving command cpio.
I was aware of the pipe symbol in Tony's post, but I got it
bass-ackwards as to which command fed which command, thanks for
straightening that out for me.
> different Unix commands can be strung together by different people
> to accomplish the same task. But just like english, one must learn
> the vocabulary, usually starting with simple words and construction,
> before one gets to the more difficult ones.
Aye, and therein lies the problem. A simple command like "ls" is quite
learnable by most Mac newbies, as are most of the options to "ls".
Even that simple command has a few options that could cause a Mac
newbie problems, the options "T" and "t" for example, which I just got
through understanding in a l-o-o-n-g recent series of posts, which
tried the patience of gurus in this NG. (sticky-bits)
Anyhow, to me it is a giant jump from understanding "ls" to
understanding the bulk of the other commands, with nothing to ease the
pain of learning except to charge in and ask questions in this NG.
That approach gets tiresome to the gurus here, which I can appreciate.
Can't be done with Unix books, IMO, so I am stuck with asking questions
supplemented by experimenting with the options to commands.
I would like to find a NG where Mac newbies frequented, helping each
other learn, to take the load off gurus in this NG who have better
things to do than answer dumb questions from newbies.
The NG "alt.sys.mac.newuser-help" does not seem to have hardly anyone
discussing the Unix side of Mac OSX, I have been monitoring it for
months, hoping such threads would get going there, no luck.
Anyhow, thanks for your excellent post geared to newbies, explanations
like that are difficult to find in the Unix books I have had contact
with.
Mark-
Mark Conrad
<to...@pcunix.com> wrote:
> > Granted that I "cd /", but there may be _several_ OSX partitions on
> > the desktop, what steers the modified 'Mybackup' to the correct
> > partition?
>
> Sorry - too much simplification.
>
> First: I assumed that /Volumes/Mybackup is the target.
Okay, that clears it up; I erroneously thought that "Mybackup" was a
previously created backup file that cpio was 'altering'.
Now I understand that 'Mybackup' is getting altered "in-place", so to
speak, (altered by cpio) at the same time that 'Mybackup' is created.
> First: I assumed that /Volumes/Mybackup is the target.
>
> Second, the "find" would need modification to exclude that. How to
> best
> do that depends on the capabilities of find, which vary from Unix to
> Unix, but if there's no better way you can do something like
>
> find / | sed "/\/Volumes\/Mybackup/d;/OtherdirIdon'tWantToBackup/d" |
> cpio /Volumes/Mybackup
Okay, that I understand, "sed" would weed out the unwanted desktop
partitions, leaving only one desired 'source' partition, i.e. the
partition I want to back up.
> I forgot to mention that cpio probably isn't aware of Mac resource
> forks either..
No problem, I am going to apply cpio to UFS volumes only.
Many thanks for your follow-up post that cleared all these points up.
Mark-
Mark Conrad
<to...@pcunix.com> wrote:
> > I would give my eye teeth to get hold of good Unix books which go into
> > great detail about all the 900 various Unix shell commands,
> > applications, etc. with great detail about _all_ the options,
> > arguments, etc. - describing what those options actually do in plain
> > language...
>
> Gaad. I have many thousands of dollars worth of books here. I figure
> about $300.00 per foot of shelf space, and I have about 40 feet
> dedicated to computer related books. Even all that doesn't begin to
> have what you ask for.
So much for those who say that a competent knowledge of Unix can be had
in a reasonable length of time, by reading the "basics".<g>
> > It would also be nice to have _extensive_ command-line examples of
> > exactly how _all_ the command-line options can be used to accomplish
> > specific tasks, instead of the hit or miss examples one usually sees.
>
> Yeah, right. Another 20 volumes just for that :-)
Hmm, maybe I could download and print up the 'free' version of all
those 20 volumes if I had a fiber-optic connection to the Internet and
a high-speed printer ;-)
> I have reviewed and recommended a number of Unix books at
> http://aplawrence.com/Books. You know enough about my background from
> reading here to know whether or not you might agree with my tastes, but
> in case it isn't obvious, I admire techy books that don't assume too
> much prior knowledge but also don't waste time with the truly trivial.
Now _that_ is useful information, I will save my pennies and get the
most useful of those books.
One more question of a non-technical nature. Do you consider your
website worth all the effort that you put into it, just curious.
Mark-
Tony Lawrence
>
> I would like to find a NG where Mac newbies frequented, helping each
> other learn, to take the load off gurus in this NG who have better
> things to do than answer dumb questions from newbies.
So you want dumb answers to your questions?
:-)
Tom Stiller
Tony Lawrence <to...@pcunix.com> wrote:
> Tom Stiller wrote:
> > In article <w6N%9.160599$VU6.1...@rwcrnsc52.ops.asp.att.net>,
> > Tony Lawrence <to...@pcunix.com> wrote:
>
> >>
> >>I forgot to mention that cpio probably isn't aware of Mac resource forks
> >>either..
> >
> >
> > No, but hfspax is aware of resource forks and will backup in the cpio
> > format.
>
> And where do we find hfspax?
Fink, among others. Google "hfspax" will turn up a slew of hits.
Tony Lawrence
> In article <VeN%9.160270$rM2.123645@rwcrnsc53>, Tony Lawrence
> <to...@pcunix.com> wrote:
>
>
>>>I would give my eye teeth to get hold of good Unix books which go into
>>>great detail about all the 900 various Unix shell commands,
>>>applications, etc. with great detail about _all_ the options,
>>>arguments, etc. - describing what those options actually do in plain
>>>language...
>>
>>Gaad. I have many thousands of dollars worth of books here. I figure
>>about $300.00 per foot of shelf space, and I have about 40 feet
>>dedicated to computer related books. Even all that doesn't begin to
>>have what you ask for.
>
>
> So much for those who say that a competent knowledge of Unix can be had
> in a reasonable length of time, by reading the "basics".<g>
It can be had, yes. Remember that Unix consulting is my occupation and
has been for more than 20 years now. It makes sense that I might need a
few more books than you do.
Also remember that in spite of that 20 years and all those books I'm
still a damn illiterate fool who stumbles through the garden half blind
and often quite confused. That's sometimes an advantage :-)
But the basics? Attainable in a few hours of study. The only hard part
is matching your learning style with the right author. Read some of my
web pages; if you find them "about right", then you'll probably like my
book recommendations. If my writings are too hard (or too basic) then
you shouldn't go by my book reviews.
>
>
>>>It would also be nice to have _extensive_ command-line examples of
>>>exactly how _all_ the command-line options can be used to accomplish
>>>specific tasks, instead of the hit or miss examples one usually sees.
>>
>>Yeah, right. Another 20 volumes just for that :-)
>
>
> Hmm, maybe I could download and print up the 'free' version of all
> those 20 volumes if I had a fiber-optic connection to the Internet and
> a high-speed printer ;-)
Which brings up a good point: Google is my best pal when I need to grok
something I haven't done before..
>>I have reviewed and recommended a number of Unix books at
>>http://aplawrence.com/Books. You know enough about my background from
>>reading here to know whether or not you might agree with my tastes, but
>>in case it isn't obvious, I admire techy books that don't assume too
>>much prior knowledge but also don't waste time with the truly trivial.
>
>
> Now _that_ is useful information, I will save my pennies and get the
> most useful of those books.
Whichever that is..
>
> One more question of a non-technical nature. Do you consider your
> website worth all the effort that you put into it, just curious.
Lordy yes.
It serves several important purposes for me:
It's a repository for knowledge I don't use often enough to keep in my
human ram. I look stuff upon my own site all the time. I had a funny
thing last summer where I was working with another consultant and we
needed a piece of trivia about an ancient piece of equipment. The other
guy went off to search the web while I continued working on some other
aspect of the project. A few minutes later he shouted "I found it in
this article by Tony Lawrence.. hey wait a minute, that's you!". Yeah -
but I had long forgotten that little trinket of knowledge.
Secondly, the articles I write always give me a better understanding of
the subject at hand. There's nothing like trying to explain something
in writing to make you realize where your weak areas are.
Finally, it's my advertising venue. Probably 70% of new business comes
across that virtual transom.
Tom Harrington
Tony Lawrence <to...@pcunix.com> wrote:
> > Hmm, maybe I could download and print up the 'free' version of all
> > those 20 volumes if I had a fiber-optic connection to the Internet and
> > a high-speed printer ;-)
>
> Which brings up a good point: Google is my best pal when I need to grok
> something I haven't done before..
Google knows and sees all. Seriously, for any technical question,
there's got to be a Google search that'll find the answer. Just watch,
the first real artificial intelligence will be a future version of
Google.
--
Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 1.3: Now runs the Mac OS X "Repair Priviliges" Utility.
See http://www.atomicbird.com/
Jeremy
>> My guess is that you can make it so. Have you looked at "bless" as I
>> suggested?
>
> Yep, it is definitely geared towards HFS+ file-systems only, not UFS.
Who says? I see no indication of that.
> Tony Lawrence suggested the Unix command "cpio", to actually alter the
> backup file itself, in order to make the backup file "compatable" with
> a fresh blank OSX UFS partition, one that contained _only_ the Mac
> OSX installed into a UFS partition.
cpio is just another archiver. My suggestion of using pax was essentially
the same thing, except that I showed you how to make a backup file, while
he showed you how to make a copy of the filesystem. (That is, in my
example, the result is one file containing the whole backup, and in his,
the result is a mirror-image of the file and directory hierarchy.) pax
can do that too, and cpio can do a single-file backup. There's more than
one way to do it.
> The idea is that cpio would modify the backup file itself, *then*
> copy the modified backup file into the 'blank' OSX partition.
I don't think you really understand. In his example, there is no "backup
file". You're copying the directory hierarchy onto another disk. That
is, if you're copying the whole OS X root into /Volumes/Mybackup, your
/etc/passwd file would be copied to /Volumes/Mybackup/etc/passwd.
This is a "live backup". This is, in fact, how I make backups most of
the time -- I copy the directory hierarchies I want to back up onto a
CD image and then burn it. It just happens that I use pax to do it,
but cpio would work just as well. I like this because, if I need to get
at just one file in the backup, I can just toss the CD in and navigate
to the file, no worrying about a restore process.
(But I don't worry about making the backup bootable, and in fact I don't
back up the system itself, only my own stuff.)
> Hopefully, it would then be both bootable, and _also_ contain all the
> personal backed-up files, their correct permissions, configurations,
> etc.
It won't be bootable any more than any other file-based backup would be.
You'll have to make it bootable, for example with "bless" or by whatever
other means Apple provides to do this.
--
Jeremy | jer...@exit109.com
Jeremy
> Now I am worried about "payback". I am building up a helluva debt
> here, doing a lotta 'taking' and not contributing anything.
>
> It is starting to give me a giant sized guilty conscience.
Eventually, when you can answer questions, do so. You don't have to
"pay back" those of us who are helping you now; your payback will be to
help other people in the future.
Also, you must have a pretty firm grasp of the "Mac" stuff, since your
only problems seem to be to do with Unix. Answer questions about that
from OS 9 users.
> I would like to find a NG where Mac newbies frequented, helping each
> other learn, to take the load off gurus in this NG who have better
> things to do than answer dumb questions from newbies.
The problem with the "newbies helping newbies" approach is that you end
up with the blind leading the blind, so to speak. What happens a *lot*
in those cases is that one person digs up some solution to some common
problem somewhere, a solution which isn't really correct, and tells
everyone, and they start parroting it to others, and no one really
understands that it's bad advice until it's so widespread that it becomes
impossible to stamp out. This is often called "Cargo cult" advice --
people are giving it out without really understanding it.
Seriously, anyone who doesn't want to waste time answering your questions
here will just be skipping them. Just please don't post false or otherwise
questionable information in the hope of trolling someone into explaining it
properly. This is really bad and your karma will go through the floor.
--
Jeremy | jer...@exit109.com
Mark Conrad
Lawrence <to...@pcunix.com> wrote:
> > I would like to find a NG where Mac newbies frequented, helping each
> > other learn, to take the load off gurus in this NG who have better
> > things to do than answer dumb questions from newbies.
>
>
> So you want dumb answers to your questions? :-)
Not really, but I can sift out the dumb answers by trying them out in
practice.
I was thinking more of each newbie learning one aspect of Unix well,
then dispensing his knowledge to the other newbies.
> > So much for those who say that a competent knowledge of Unix can be had
> > in a reasonable length of time, by reading the "basics".<g>
>
> But the basics? Attainable in a few hours of study.
Or a few weeks in my case. I agree that the usual Unix file-shuffling
etc. can be learned fairly quickly, such that a Mac person could do
almost everything from the command-line that he does from the Mac GUI,
but why bother to even learn those types of Unix "basics" - when I
already have the Mac interface to do all that basic stuff for me.
What I meant by "a competent knowledge of Unix" was the extended
features of Unix that just plain are not available in the Mac GUI.
Those features can't be learned in a few hours. Unlikely that they
could be learned in a few months. A few years, perhaps.
> Which brings up a good point: Google is my best pal when I need to
> grok something I haven't done before.
Hmm, maybe I could do an initial Google search using "Learning Unix" or
"Teaching Unix" then grep-filter it somehow to reduce the number of
hits and ferret out the Mac OSX/Unix newbie hangouts.
Tom Harrington wrote:
> Google knows and sees all. Seriously, for any technical question,
> there's got to be a Google search that'll find the answer. Just watch,
> the first real artificial intelligence will be a future version of
> Google.
That is another book I wish someone would write, namely how to best do
a search of Google to turn up the info' one is after.
> > One more question of a non-technical nature. Do you consider your
> > website worth all the effort that you put into it, just curious.
>
> Lordy yes.
>
> It serves several important purposes for me:
>
> It's a repository for knowledge I don't use often enough to keep in my
> human ram. I look stuff upon my own site all the time.
Many years ago, when my neurons were still intact and my synapses were
still snapping, I knew a few thingies. What frightens me now is that I
read my own ancient scribblings and think to myself:
"Gadd, that is a really intelligent article" - - before I realize
that I wrote the article myself when I was younger.
Enough of this ruminating, gotta get back to work learning Unix.<g>
Mark-
Ernie Klein
Mark Conrad <nos...@iam.invalid> wrote:
> Aye, and therein lies the problem. A simple command like "ls" is quite
> learnable by most Mac newbies, as are most of the options to "ls".
>
> Even that simple command has a few options that could cause a Mac
> newbie problems, the options "T" and "t" for example, which I just got
> through understanding in a l-o-o-n-g recent series of posts, which
> tried the patience of gurus in this NG. (sticky-bits)
>
>
For the most part, it is not necessary to learn or remember all of the
options for a command. Options, like commands, have evolved over time.
When a user needed to do a task but there was no existing command that
would work, but there was a command that was very close, rather than
write a new command from scratch, it was much easier to simply add an
option to the existing command. In many cases these options have been
passed on for years but have very limited use. One such option was in
the 'ls' command that you mentioned. I don't think it is in this
version of Unix, but the option allowed printing the octal value in
brackets instead of a '?' for non-printable characters. In most cases
you would not care what the actual value of the non-printable character
was, but in certain cases that information was of value.
Another option in the 'ls' command is the '-i', or list inode number
option. Most Unix 'users' will go through life never knowing what an
inode is, let alone needing to know it's number. In some systems their
are inode editors that allow one to correct corruption in an inode in a
running system in order to fix file system problems without rebooting
the system and this option is very valuable, but the normal user will
never need it.
I point this out because you seem to think that if you don't understand
all of the options for a new command you are learning, then you are
missing something and get frustrated. For the most part, when I see a
new command, I don't care if I fully understand all of the options, some
that have very limited and obscure use, only the ones that I need to
know.
-Ernie-
David Eppstein
Ernie Klein <eckleins...@pacbell.net> wrote:
> One such option was in
> the 'ls' command that you mentioned. I don't think it is in this
> version of Unix, but the option allowed printing the octal value in
> brackets instead of a '?' for non-printable characters. In most cases
> you would not care what the actual value of the non-printable character
> was, but in certain cases that information was of value.
Actually, on OS X, those "non-printable" characters are generally
printable unicode UTF-8 characters, and the "-q" option which turns them
into question marks (on by default in the terminal) should probably be
removed so that people who put accents in their filenames can see them
properly.
Not that this takes anything away from your actual point...
--
David Eppstein UC Irvine Dept. of Information & Computer Science
epps...@ics.uci.edu http://www.ics.uci.edu/~eppstein/
Ernie Klein
David Eppstein <epps...@ics.uci.edu> wrote:
> In article <eckleinspammenot-8E...@news.newsguy.com>,
> Ernie Klein <eckleins...@pacbell.net> wrote:
>
> > One such option was in
> > the 'ls' command that you mentioned. I don't think it is in this
> > version of Unix, but the option allowed printing the octal value in
> > brackets instead of a '?' for non-printable characters. In most cases
> > you would not care what the actual value of the non-printable character
> > was, but in certain cases that information was of value.
>
> Actually, on OS X, those "non-printable" characters are generally
> printable unicode UTF-8 characters, and the "-q" option which turns them
> into question marks (on by default in the terminal) should probably be
> removed so that people who put accents in their filenames can see them
> properly.
>
> Not that this takes anything away from your actual point...
Exactly. On the Unix system that I am most familiar with, anything
outside of the traditional ASCII character set was 'non-printable'. I
have very little experence with the OS X version of Unix. This only
emphasizes the point that command options can be very system dependent
and options that are very useful on one Unix system may be almost
useless, or don't even exist, on another.
-Ernie-
Tony Lawrence
> Another option in the 'ls' command is the '-i', or list inode number
> option. Most Unix 'users' will go through life never knowing what an
> inode is, let alone needing to know it's number. In some systems their
> are inode editors that allow one to correct corruption in an inode in a
> running system in order to fix file system problems without rebooting
> the system and this option is very valuable, but the normal user will
> never need it.
Just want to point out that there are other reasons to see the inode.
An identical inode number indicates that x and y are hard links. If x
and y are not together, "find -inum" will locate the twins.
Mark Conrad
<nos...@iam.invalid> wrote:
For those Mac lurkers who want to know what-on-earth the Unix gurus are
talking about, regarding "inodes" - - -
- - - All You Never Wanted To Know About "Inode" - - -
( inode number is sometimes called "file serial number" )
I did a 3-minute search of Google, using the words: " Unix and
inode" (without the quotes)
It turned up something like 47,000 hits, I just punched the first hit
that struck my fancy.
Basically, inodes are data structures describing a file, who "owns" it,
what its "permissions" are, what time it was last accessed, modified,
the directory path to get to the file, a table containing the block
addresses of where the file pieces are scattered around the disk, the
file size, and a bunch of other data pertaining to the individual file.
These data structures describing each file are stored sequentially in
an array, and each one of the data structures is assigned a number,
called an "inode" number.
I would imagine that having access to this "inode" information might
help a Mac user in some cases, but I am not presently aware of
how/when/why/where it might help, so presently I am not actively
learning more about inode.
From Terminal, using list "ls": ls -i <file to be listed>
...and the "inode number" will be the very first returned entry when
the file is listed, but I don't have the foggiest idea of how to use
that number to display all the inode information about the file though.
Mark-
Mark Conrad
Ernie Klein <eckleins...@pacbell.net> wrote:
> I point this out because you seem to think that if you don't understand
> all of the options for a new command you are learning, then you are
> missing something and get frustrated.
Yep,it is my curious nature. I figure it won't do much harm if I go
over any options of interest, once lightly. Might pay off big time in
the future when I have a need for that option, assuming I can find my
notes about it.
Is there an easy way to use the inode number to display all the inode
data about a file?
I noted that the man page for "ls" describes the "i" option as listing
the "file serial number".<g>
Mark-
Tony Lawrence
Any file system debugger can display a particular inode. However, the
only information there that is not readily available other ways (ls -l
etc.) is the actual storage allocation, which is seldom of interest,
although that info would give you knowledge of file fragmentation if you
felt you needed to know that (and for a lot of reasons, you probably don't)
On a system that has the somewhat common "fsdb" (Mac OS X does not) you
could dump out inode 54618 with
echo "54618i" | fsdb /dev/root
What is interesting is this comment from
<http://www.usenix.org/publications/library/proceedings/usenix2000/invitedtalks/sanchez_html>
"It is worth noting that the difference is behavior is in part due to
the implementation of the respective filesystems. In UFS, meta-data is
store with the file's inode, and inodes are stored separately from file
data. In HFS+, the file meta-data is stored with the file data; there
is no inode. "
And yet, we can apparently ACT as though these did have inodes: hard
links work, ls -li displays a number that is relevant, etc.
<http://developer.apple.com/technotes/tn/tn1150.html> talks about how
HFS+ is implemented, but doesn't explain how that part of the
abstraction works.
Mark Conrad
<to...@pcunix.com> wrote:
> > Is there an easy way to use the inode number to display all the inode
> > data about a file?
> >
> > I noted that the man page for "ls" describes the "i" option as listing
> > the "file serial number".<g>
>
> Any file system debugger can display a particular inode. However, the
> only information there that is not readily available other ways (ls -l
> etc.) is the actual storage allocation, which is seldom of interest,
> although that info would give you knowledge of file fragmentation if you
> felt you needed to know that (and for a lot of reasons, you probably don't)
VERY interesting posts you grind out, sir :)
Now I gotta beat the bushes to find an "inode editor" which will work
with Mac OSX UFS partitions, because I wanna jury-rig a defragmenter
for UFS partitions.
Idea is if I know exactly where all the pieces of every file are
scattered, I can pack the pieces together with dd, then go back and
edit the inode table entries to reflect the new location of the
"packed" file fragments - - - all this action automated by a shell
script, of course.
Probably several reasons why my plan won't work, but ignorance is bliss.
At times I want to pack all the files of an out-of-use UFS partition to
one end of the partition, for various obscure reasons of my own, and I
can't find any commercial defrag' utilities for an unused Mac OSX UFS
partition. (HFS+ yes, but UFS, no)
Mark-
Tony Lawrence
> In article <eQq0a.6034$SD6.40@sccrnsc03>, Tony Lawrence
> <to...@pcunix.com> wrote:
>
>
>>>Is there an easy way to use the inode number to display all the inode
>>>data about a file?
>>>
>>>I noted that the man page for "ls" describes the "i" option as listing
>>>the "file serial number".<g>
>>
>>Any file system debugger can display a particular inode. However, the
>>only information there that is not readily available other ways (ls -l
>>etc.) is the actual storage allocation, which is seldom of interest,
>>although that info would give you knowledge of file fragmentation if you
>>felt you needed to know that (and for a lot of reasons, you probably don't)
>
>
> VERY interesting posts you grind out, sir :)
>
> Now I gotta beat the bushes to find an "inode editor" which will work
> with Mac OSX UFS partitions, because I wanna jury-rig a defragmenter
> for UFS partitions.
You don't need it.
>
> Idea is if I know exactly where all the pieces of every file are
> scattered, I can pack the pieces together with dd, then go back and
> edit the inode table entries to reflect the new location of the
> "packed" file fragments - - - all this action automated by a shell
> script, of course.
>
> Probably several reasons why my plan won't work, but ignorance is bliss.
>
> At times I want to pack all the files of an out-of-use UFS partition to
> one end of the partition, for various obscure reasons of my own, and I
> can't find any commercial defrag' utilities for an unused Mac OSX UFS
> partition. (HFS+ yes, but UFS, no)
The reason you can't find it is because there's no money in it. There's
very little need for defragging Unix file systems. Now and then someone
has come out with a commercial defragger for xyz Unix - invariably it
never sells, because IT ISN'T NECESSARY.
However, since you insist: A UFS file system is going to be similar in
concept to the inode dumper I wrote about at
http://www.pcunix.com/Unix/bfind.html
THAT CODE IS NOT GOING TO WORK. However, something very close to it is
your starting point, and it should give you the clues you need to get
started. It's uncomplex C, minimally commented, an no, I'm not
interested in rewriting it for UFS.
Mark Conrad
<to...@pcunix.com> wrote:
Thanks for listing the C code for the "inode dumper", for SCO Unix
3.2v4.x - - - even though the C code won't work with OSX, like you say,
it should give me enough clues to create my own inode-editor, assuming
I can't find one ready-made that will work with OSX.
My "Mac OSX Unleashed" book implied that "inode-editors" for OSX were
available, but gave no references as to where to find them.
I am rapidly getting backed up on 'future projects' here, so will have
to disappear from the NG in order to catch up.
I want to consolidate what I have learned so far, and do a heck of a
lot of experimenting with more tcsh shell commands in order to better
understand them.
Thanks to Unix gurus like you, I have been 'kick-started' on Unix and
can almost fend for myself, as regards future learning.
Without said kick-starting, I would never have got going on Unix, and
no doubt would have given up altogether.
The "Mac Terminal" code-examples of shell commands that work with OSX
were especially valuable in giving me the preliminary knowledge to
learn enough Unix to get me going, whereas the Unix/Linux books failed
in this respect. (at least for me)
Next most important in 'getting-me-going' were the explanations from
Unix gurus in this NG, which there was no equivilent to in the books.
(i.e. - the books that I had, that is)
If a Unix 'student' can't understand how a command works from Unix
books, or from the 'man' pages, or from his own experimentation with
the command, and if he does not know how to use "Google" to find the
info' he needs - then one of his few remaining recourses is to ask
questions in this NG.
Thanks again,
Mark-
Tony Lawrence
>
> Thanks to Unix gurus like you, I have been 'kick-started' on Unix and
> can almost fend for myself, as regards future learning.
>
I know you mean well, but please understand that some of us (me) don't
want to be called "gurus".
There are real Unix gurus, and I have had the extreme pleasure of
knowing one or two, but the vast majority of those who make such claim
are nothing but poseurs.
Since I am neither a real Guru nor a pretentious wannabeee, I don't want
that term anywhere near me.
Mark Conrad
<to...@pcunix.com> wrote:
> > Thanks to Unix gurus like you, I have been 'kick-started' on Unix and
> > can almost fend for myself, as regards future learning.
> >
>
> I know you mean well, but please understand that some of us (me) don't
> want to be called "gurus".
Sorry, I did not know you were sensitive about that.
What is your definition of a Unix "guru" ?
Mark-
Tom Stiller
Mark Conrad <nos...@iam.invalid> wrote:
It's sort of like "expert" -- a compound word formed from "ex" meaning
"former" and "spurt" meaning a drip under pressure".
No one wants to be called one.
Tony Lawrence
Someone who is really an expert, and not a dilettante like me. Dennis
Ritchie, Ken Thompson, Eric Raymond, Richard Stallman, Linus Torvalds,
Kernighan and Pike, , Richard Stevens et al.
Those are the kinds of people who actually are Unix gurus. I think it's
pretty obvious that I don't compete at that level.
So lets move on down to the common folk. More than 99% of the time,
anyone else who calls themselves a guru not only is not, but usually is
an incompetent braggart who has very little real skill or knowledge.
These are often the kind of people who change root's shell to csh, have
web pages that brag about how brilliant they are, etc. While none of us
can be completely aware of our own incompetence, these people are
completely unaware. Their attitudes of superiority often cause them to
be nasty ond overbearing toward those who haven't yet attained the
knowledge that they have. Although he's never made claim to "guru"
afaik, we have someone like that here - the obnoxious dolt who thinks
everyone else is incredibly dumb and is probably in most of our filters
by now. I'm not one of those jackasses either.
So because I can't claim real guru status and don't want to be
associated with the rest, I don't want to be called "guru" or even
"expert". If you want, you can use the word "helpful", because that's
all I'm aiming for.
Mark Conrad
<tomstiller-0867E...@news.comcast.giganews.com>, Tom
Stiller <tomst...@comcast.net> wrote:
> It's sort of like "expert" -- a compound word formed from "ex" meaning
> "former" and "spurt" meaning a drip under pressure".
>
> No one wants to be called one.
Sorry, I will avoid using it in the future.
I thought it was a complimentary term for someone who knew a lot.
(probable is, when applied to a "real" expert, I would assume)
Mark-
Jeremy
>> It's sort of like "expert" -- a compound word formed from "ex" meaning
>> "former" and "spurt" meaning a drip under pressure".
>>
>> No one wants to be called one.
>
> Sorry, I will avoid using it in the future.
>
> I thought it was a complimentary term for someone who knew a lot.
It's a reality of Unix culture -- there's always someone who knows more
than you do. *That* guy is the "expert". If you asked him, though, he'd
point to someone else as the "expert".
Unix people also tend to be humble. We don't have to show off. (And if
we do, the guy who knows more than we do will just come along and make us
look foolish, merely by pointing out a better way to do it. There is
always a better way to do it, unless there isn't, and if you know there
isn't, there probably is.)
--
Jeremy | jer...@exit109.com
Tom Harrington
Tony Lawrence <to...@pcunix.com> wrote:
I've always thought that the real guru is someone who is regarded as
such by others. If someone has to tell you they're a guru, they're not.
Anthony Lawrence
<jer...@exit109.com> wrote:
And if there isn't, somebody will move heaven and earth to invent a
better way just to prove a smartass wrong.
Anthony Lawrence
<t...@pcisys.no.spam.dammit.net> wrote:
But the relative competence of the person doing the regarding is
important. To a newbie, I'm pretty damn sharp. To Richard Stevens,
I'm a bumbling dope.
It's all very relative, but I know enough about Unix to know that what
I don't know is a hell of a lot more than what I do.