NeXT Computers

NeXT Computer, Inc. => NEXTSTEP / OPENSTEP Software => Topic started by: pentium on September 06, 2015, 04:36:35 am

Title: TAR command to archive MO disks
Post by: pentium on September 06, 2015, 04:36:35 am
I know I can just use..

dd if=/dev/od0a of=/foo/bar/file.img

...to make a complete image of an OD cartridge but I'm trying to see if I can instead stuff everything into a tar file instead for a bit more portability. The problem is that you can't just tar -cvf /dev/od0a because it's not an actual file so I'm a touch lost on what to do here.
Title: TAR command to archive MO disks
Post by: barcher174 on September 06, 2015, 07:46:53 am
Can't you just tar the directory it mounts to on root?
Title: TAR command to archive MO disks
Post by: pentium on September 07, 2015, 03:55:57 am
I don't actually know where it mounts.  :oops:
Title: TAR command to archive MO disks
Post by: barcher174 on September 07, 2015, 05:35:24 am
Literally to the root directory. So if you mount a disk named "newDisk" you would access it at "/newDisk"

If for some reason your system is configured differently, keep the console log open when you mount it. It will give you the mount point.


--
Brian
Title: TAR command to archive MO disks
Post by: pentium on September 16, 2015, 04:22:20 pm
While verifying that I had imaged the disks properly I noticed that I was missing files. Apparently tar is skipping a few because the filenames are too long. The supposed fix is tar -Ecvf /archive.tar /source/folder

...according to this page (http://unix911.blogspot.ca/2011/10/tar-file-name-too-long-how-to-fix.html) but it seems that Tar on NeXTSTEP doesn't know what the E modifier stands for. It was apparently added to tar years after NeXTSTEP 3.3.

Edited: Adding insult to injury, it seems the latest releases of gnutar won't even configure on NeXTSTEP. Something about the shell being too old.

Edited: Ah right. Kb7sqi built gnutar for NeXTSTEP a while back. It's just not hosted locally in the file archive.
Title: TAR command to archive MO disks
Post by: barcher174 on September 16, 2015, 07:06:03 pm
Your edit beat me to it. :)

Here is the file for in case anyone stumbles across this:

https://drive.google.com/open?id=0B0gDYBETjc4Wb1RzbFE5YW5oZXc
Title: TAR command to archive MO disks
Post by: pentium on September 16, 2015, 09:01:08 pm
Hmmm. After only two disks I'm noticing that the regular syntax
gnutar -cvf /image_name.tar /path/to/folder
produces archives that are not the same size as the disks. They are always smaller. There is no compression happening that I am aware of. Is it still dumping files? I'm not seeing any errors with -v so I'm not sure what is up. Wish I could compare but cmp doesn't work with tar files.
Title: TAR command to archive MO disks
Post by: barcher174 on September 16, 2015, 10:05:00 pm
Does the -v give a list of all the files you could at least compare with the contents of the directory?
Title: TAR command to archive MO disks
Post by: pentium on September 16, 2015, 10:09:09 pm
-v gives a list alright but there's thousands of files. I've already just tried using gnutar's compare function
gnutar -v --compare --file=/OpticalDisk.tar -C /OpticalDisk
...but that just returns all errors that there's nothing found. Like, it doesn't even try searching the MO drive.
Title: TAR command to archive MO disks
Post by: gtnicol on September 17, 2015, 12:20:46 am
When I archive disks, I use tar, dump, and also take direct sector dumps. I always do it at least twice to compare.

You can mount the disk image directly on modern machines.
Title: TAR command to archive MO disks
Post by: pentium on September 17, 2015, 02:52:12 am
But how easily accessible are they when they are just dd image files? The imaged disks are not staying with me. They are being delivered to someone else whose recent knowledge with computers is unknown.

Edited: Now that I've spent a few more hours working on this I am starting to suspect that the inconsistent size issue is really just the file shrinking as it moves from the formatted blocksize of the MO disk to the filesystem on the hard drive and the data itself is still completely intact.