I noticed that the update and append options for tar do not work on compressed archives. Which led me to noticing that tar can be and must be used to create non-compressed archives. (otherwise there would be no point of the update and append options)

So my question is, in what kind of situation would tar be used to create uncompressed archives? What would be the advantage of using tar over simply copying the files to a folder? It just seems like every situation I can think of off the top of my head, where you might want to be able to make a bunch of files into one file, it seems like you would also want to compress it.

I don't actually have any problem, with it or anything. I'm just asking out of curiosity.

Thanks in advance!!

tar has a bazillion options and nuances but I see it mainly as a means of packaging large numbers of files so they can be handled as one, but still not lose their identities.

For example, to backup a directory, you first run tar so that you have only one file to deal with--eg sending to a server by ftp.

Thanks for the reply, but it seems to me if you where going to use tar to "zip" a bunch of files into one for transferring by FTP, or any other network protocol, it would be extremely worthwhile to compress it, since in almost all cases, it will take less time to compress, and transfer, than to transfer at full size.



My question is specifically, in what kind of situation would you want to use tar, without compression.

For anything pertaining to networks, it seems you would surly want to compress it.

For anything not having to do with networks, it seems like if you didnt want to compress it, why wouldnt you just make a directory and copy your files there. you could still move around it around on the system as one unit, by copying the folder.

I know this doesn't qualify, since you're thinking of leaving the product behind, but I use tar without compression to move stuff around if I need to.

And there are probably dozens of other uses. And, if the tar version doesn't support the compression you want, you would want an uncompressed file that you could then compress with the other tool. Tape drives which have automatic (and efficient) compression built in -- since it saves processor and the end result will likely be the same usage of the media.

Beats me... but if you want it uncompressed you'll be glad it's the default and not the other way around.

tar without compression is still useful, but maybe not very common---esp. since you can tar AND compress in one command. (tar -czvf <target> <source>)

Note that there are MANY Unix/Linux commands which might rarely be used alone. The whole idea is to have the fully modular range of tools--where some combination can be found for every task.

In your example about moving the files, why wouldn't you just do it this way?

or
Is there an advantage to doing it with tar?

(Not trying to be a smarta$$ or anything, I seriously wouldn't know if there was or was not an advantage.)

The system time is what matters here (although you can add the system and user times together). The real time is based on how busy the system was. Obviously, I was doing more stuff when I ran the tar command. So even though it's quicker, it finished in longer real time. The cp command takes almost twice as much system time. And the totals (39.02 seconds for tar & 57.54 seconds for cp show a pretty big lead). tar was almost 33% faster... and it gets better as the amount of data grows... this was only 4GB... and had no directories. With directories tar is even better than this. Basically, the more data and the more complex the structure... the more appealing it becomes to use tar.

And, for this test I gave cp all the advantages. I ran it second so it had the advantage of files cached in memory so it saved on some initial read time and I went and made a cup of tea after I started the cp command. I sat here and used the computer when the tar command was running so I had the system under load. Which means it was also reading from other parts of the disk as well. On perfectly identical conditions, tar would look that much better.

Also, a very important note from the cp manpage:
This is a major issue for scripting and/or some uses. Silently failing is just not something that can be accepted for some tasks. If you're moving /tmp for example and it fails to set the sticky bit... you're going to be very unhappy rather quickly. Or, you may not notice at all and have a huge security hole.

tar also respects ACLs... which cp does not.

It depends on what you're doing... basically, if I'm copying or moving a directory structure then I'm almost always going to look at tar. If I'm copying or moving a couple files... then cp is okay.

For me, the real advantage of tar is simply housekeeping, + maybe being much easier to use with command-line ftp. Doing put and get with many files in many different folders is a real pain in ftp.

Use a GUI to assemble stuff to be archived into one folder, tar it and then moving it around (in any protocol) becomes easy.

Thanks for taking the time to explain all that!! I figure the more of this kind stuff I learn, the better I can find my own way around, and do things more efficiently!

No problem. It's something I don't think about too much anymore because I got into the habit years ago. I had to sit here and ask myself, "Now, why do I do that again?" Even though I knew there were good reasons. I tend to think of some commands with a "level of effect" view. For example, when it comes to moving or copying things from one location to another, I tend to think of four different sizes of movement and use the tools I prefer for them.

File[s]: cp
Director{y,ies}: tar
File system[s]: dump (restore)
Device[s]: dd

Then there's always exceptions and you need to know the particulars of the situation: For example:

mv dirname ../foo

That could be a one step command (if you're just renaming and relocating the directory on one filesystem). But if ../foo crosses mount-points, then you're dealing with much more io and should consider what you want. Depending on the size, mv might be just right. Or maybe tar is better (usually it is for me, as I said, because I copy first before I remove to ensure things don't break)...

And these are just my preferences and what I am used to. I'm not even going to say I recommend them. Only that they work for me. Only you know your system and the particulars of it.