8

I did a network backup of my login area in preparation for reformatting the volume in which it resides to make it bootable on my old Power Mac G5 running the very latest release of Leopard.

Though I don't believe this symptom is a function of the actual tar invocation, here is the actual command for completeness:

   bill@r2d2-2:~
   [108] (sudo tar cf - -C /Volumes/usr1 Users) | gzip -c - | ssh whmcclos@mbp \
             'cat > /Volumes/link2TMS/r2d2_usr1_Users.tar.gz'
   tar: Users/bill/Library/Acrobat User Data/8.0_ppc/Synchronizer/Commands: socket ignored
   tar: Users/bill/Library/Acrobat User Data/8.0_ppc/Synchronizer/Notification: socket ignored

Here are the two socket files which tar is ignoring

bill@r2d2:~/Library/Acrobat User Data/8.0_ppc/Synchronizer
[11] ls -larhdt *
drwx------  3 bill  staff   102B Jun  4  2010 metadata
-rw-r--r--  1 bill  staff     0B Jan 20 13:05 adobesynchronizersu80
srwxr-xr-x  1 bill  staff     0B Jan 20 13:05 Notification
srwxr-xr-x  1 bill  staff     0B Jan 20 13:05 Commands

Haven't worked with creating sockets in a few years, and I'll know what to do once I get a hint. As the Title says, how do I backup and then restore these files given that tar has ignored them?

10

You don't.

Unix local sockets are created as soon as a program attempts to listen on the given path for connections, and despite being a type of file they only act as pointers to in-memory structures; so they are useful only as long as the program is still running (and only within the same machine; no NFS or anything such).

After the program exits, the socket file is no longer useful (and is normally deleted by the program itself); in fact, if the program gets restarted, it has to delete the old socket before listening on the same path – otherwise it would receive an "Address already in use" (the same as if two programs were trying to take the same TCP port).

This is somewhat different from named pipes (aka fifos), which work in a much simpler way (one process writes, one process reads) and therefore are reusable; a named pipe can be created using the mkfifo or mknod p … commands.

7
  • I was indeed confusing FIFO's, which I've programmed and used, with sockets. There are also those pesky albeit extremely important/useful b(lock) and c(character) special files in the /dev folder, and as I recall, they don't tar up either. Thanks for the quick response. – Billy McCloskey Jan 23 '14 at 5:25
  • 1
    @BillMcCloskey: tar can archive device nodes, but needs root privileges to extract them. But usually you can skip all of /dev too, since modern systems create necessary device nodes on boot. – user1686 Jan 23 '14 at 9:14
  • Glad to hear that /dev file creation has evolved to be more dynamic; think I recall using mknod in the days of my first slackware installation. Wanting to see what I may be in for with this relatively new leopard box, I did a sudo tar cf - /dev > /dev/null, only to see tar: /dev/fd/3: Cannot stat: Bad file descriptor. As memory serves, I think that's a floppy drive which I know my PPC G5 is missing, though I do have a USB floppy drive if the need ever arises! LOL Thanks again for your insight - most helpful. – Billy McCloskey Jan 23 '14 at 15:24
  • Yes - Linux had a "devfs" for a while (though it was quite unusual); later, /dev was made a simple tmpfs in which the udev daemon created all device nodes from kernel events; this has existed for over a decade – I find references to udev's old name "kerneld" from 1997. Recently, this was moved back to the kernel again – /dev being a special kind of tmpfs where the kernel itself makes device nodes appear (in a much simpler way than devfs did, though) and udev only adjusts modes/ownership/symlinks. I do not know about OS X, but I assume it too uses a dynamic /dev, maybe like devd in other BSDs. – user1686 Jan 24 '14 at 9:40
  • As for the /dev/fd/ directory, that's not floppy drives – it contains special files corresponding to the program's own file descriptors. For example, opening /dev/fd/2 (or the /dev/stderr symlink) is equivalent to calling dup(2). Generally, it is a good idea to tell backup tools to either ignore /dev completely, or to never cross filesystem mount points (assuming /dev is a mount point), because it is certainly useless to have backups of /dev or virtual filesystems like Linux /proc and /sys, or FreeBSD /kern. – user1686 Jan 24 '14 at 9:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.