From: Jerry Peters on
Kaz Kylheku <kkylheku(a)gmail.com> wrote:
> On 2010-01-02, Eze <garzon.lucero(a)gmail.com> wrote:
>> I see the point of using tar in order to, say, send a whole directory
>> as a single attachment file. I realize historically this "tape
>> archive" utility may have been needed for some technical reasons. But
>> I don't see the advantages of using tar to back up some files and copy
>> them to some external storage device. Couldn't you just cp? The files
>> would already been untarred...
>
> cp requires a filesystem, which is a structured organization of data.
>
> tar uses ... a structured organization of data. Hmm!
>
> The difference is that tar's data structure is not mounted by your kernel
> into the usual filesystem space, so you are using a different ``API''.
>
> But that can be changed with a suitable piece of software, like
> tar support in the kernel, or through a user space loop like Linux's FUSE.

Or mc. I often use mc if I just want 1 or 2 files out of a large
tarball.

Jerry
From: Alan Curry on
In article <20100106125524.321(a)gmail.com>,
Kaz Kylheku <kkylheku(a)gmail.com> wrote:
>On 2010-01-02, Eze <garzon.lucero(a)gmail.com> wrote:
>> I see the point of using tar in order to, say, send a whole directory
>> as a single attachment file. I realize historically this "tape
>> archive" utility may have been needed for some technical reasons. But
>> I don't see the advantages of using tar to back up some files and copy
>> them to some external storage device. Couldn't you just cp? The files
>> would already been untarred...
>
>cp requires a filesystem, which is a structured organization of data.
>
>tar uses ... a structured organization of data. Hmm!
>
>The difference is that tar's data structure is not mounted by your kernel
>into the usual filesystem space, so you are using a different ``API''.
>
>But that can be changed with a suitable piece of software, like
>tar support in the kernel, or through a user space loop like Linux's FUSE.

Let me add something: not going through the kernel is an advantage
sometimes. Since the tarball is seen by the kernel as a single big file,
creating it doesn't require the creation of a zillion inodes, all being
individually cached in kernel memory for some unpredictable amount of time
during and after the backup, which is what you get with cp -a.