So if one wants to archive large tree-structure and split it to eg. 60 GB files, one can do:
But let's assume, the /mnt/usb64g is a NTFS/exFat usb stick of size 64 GB and the /home/user/hugedir is size 256 GB. Let's also assume, there is no enough space in local hard drives to do it there first and then transfer it part by part to 64 GB USB-stick, which is then used to copy file to an another PC.

The purpose is to transfer this hugedir to another machine by the 64 GB USB-stick, part by part. No network. (No fancy USB3.0 USBA - USBA cable, which I Googled could be possible but usually is not.)

Is there any more suitable program but tar+split which would have a pause between writing the chunks? Ideally split-program would have some --pause option, which when have written one chunk, would wait for user keypress before starting to write next one.

tar has -L option, but it not suitable when compression is used.

I don't understand why it has to be compressed.

You could probably do it as follows:
The skip option skips the first 60000 input blocks.

Then assemble the pieces on the other machine.

Disadvantage: You run the same huge tar command several times. But at least, you get compression.

1 members found this post helpful.

I would rather try to split the source of that tar into smaller parts (subdirs?), which will fit into that usb stick.

Perhaps a little shell script

1 members found this post helpful.

I don't understand why it has to be so complicated. Go buy a 1T external disk - dime-a-dozen these days.

That would be my route too, (external disk) - but I'd look at the scripting option in regard to the actual question.

I have not used it in a long time, but I used to use dar for splitting large backups onto multiple CDs.

2 members found this post helpful.

When I was asking the question, it was not possible to get external 1TB disk. And I was wondering this as a challenge and which should not be so difficult to do. But it seems to be.

Both solutions #4 and #7 work if all the pieces of the huge tar file can be stored in the target machine first before extracting. But neither works by using one and only one piece at time.

Solution #4 works, if target machine has free space twice of size hugedir (the splitted tar file is xz-compressed). It needs all pieces of the splitted tar file concatenated in target machine to get extracted.

I tried to pipe it through fifo (mkfifo) but it didn't work either:

Extract1:
It will hang and wait for data from fifo.

Extract2: Concatenate the first transferred piece to fifo:
Fails with error message:
Solution #7 using dar worked, but seems like it requires all pieces twice, or at least I couldn't get it work if I removed the transferred chunk every time "dar --extract" already had processed it once.

Create:
Extract:
When extracting it asks volumes 1, 2, 3, 4, ... but after the last volume/chunk, it wants volume 1 again, and then 2, - wants to read every chunk two times. So here again, if there is not enough space to have the hugedir (256 GB) twice (the second one is xz-compressed though), this solution does not work.

Using tar without compression works:
Create:
In between here transfer the 64 GB USB flash drive between the source and target machines 2x four times.
Extract:
(Disclaimer: I didn't try this really with 60G "tapes", but with smaller dir and 100k tapes.)

The --tape-length (-L) method with tar does not work with compression though. In fact, not even split having --pause option would work, because tar refuses to extract files from compressed tar file piece by piece.

One solution is to compress the files first in the source machine, transfer with "tar -L", then decompress in the target machine:
Transfer with "tar -L" in pieces and then decompress:
Compression with tar and using fifo (mkfifo) would work, if somehow fifo would not give EOF (end of file) when the parts are concatenated in in and "tar xJf" reads from there. There should be FIFO, where one must explicitly tell when EOF is outputted. If files are concatenated in it, and read out, it won't tell there is nothing to be read anymore. (I tried Goggling around but found nothing suitable.)

causes an EOF when the cat command ends.

Using a shell loop again
Now the output stream (to the fifo) gets an EOF when the loop ends.

With a process substitution the shell handles the fifo (or an equivalent mechanism)
And, if no special file descriptor is used, you can use a pipe
You might want to query the inp variable to gracefully end the loop if a certain value is met.
And you might want to increment the .1 to .2 etc. via a variable.

1 members found this post helpful.