Tar : Cannot open: Input/output error

[mattfletcher]

Can anyone tell me why this does not work?

tar cfz "bigfile_`date '+%R-%F'`".tgz bigfile.matt
bigfile_16: Unknown host
tar: bigfile_16\:55-2009-02-18.tgz: Cannot open: Input/output error
tar: Error is not recoverable: exiting now

I'm running a script in cron that creates very large log files every four hours, so at the end of the script i want it to tar the log file and name it with a date / timestamp as there will be lots and lots of these files if i ever get it to work.

I suspect it has something to do with the date format having strange characters and or spaces ??

Thanks

[smpoole7]

You may have a formatting error, but on first glance, you need to put the "f" spec last in the options. That's how you specify the filename.

[ken_yap]

No, as c doesn't take an option, so f will take the next one.

You were right about strange characters. The problem is the colon generated by the date command. Tar has been enhanced to write to remote tape devices via rmt so that part of the filename before the colon is treated as a hostname. What you need is the --force-local option to defeat this:

tar cfz  "bigfile_`date '+%R-%F'`".tgz --force-local bigfile.matt

Notice the unusual position of the --force-local option due to constraints of the other options.

[smpoole7]

No, as c doesn't take an option, so f will take the next one.

Proof that you can learn something every day, if your mind is opened. I did NOT know that. I thought you had to put CLI arguments in "parsed" order. I even looked through the "tar" manual and didn't see anything obvious (though I can't claim to have read it word-for-word, all the way through).

[ken_yap]

tar is a bit unusual because it historically didn't use the - convention for options and the - and -- conventions are a GNU enhancement. Since all the options are bundled all at the beginning, the only logical way to handle arguments is in the order of appearance of the options. Say for example you are using tar in classic mode and options cfbv, where b is blocking factor, say pick 20. It would have to be written as

tar cfbv outputfile 20 inputfiles

or

tar cbfv 20 outputfile inputfiles

Of course, blocking factor is of little consequence for disk file output, only for tape devices.

[mattfletcher]

No, as c doesn't take an option, so f will take the next one.

You were right about strange characters. The problem is the colon generated by the date command. Tar has been enhanced to write to remote tape devices via rmt so that part of the filename before the colon is treated as a hostname. What you need is the --force-local option to defeat this:

tar cfz  "bigfile_`date '+%R-%F'`".tgz --force-local bigfile.matt

Notice the unusual position of the --force-local option due to constraints of the other options.

Thats fantastic, thanks very much

[smpoole7]

tape devices.

Somewhere around here, unless it has finally been thrown away, I actually have an old tape drive. We haven't used it in years.

I knew that tar was old, and that it was originally targeted to tape backups, but ... wow.

[ken_yap]

That's what the t in tar stands for, after all. Would you believe undergrad CS courses used to teach the importance of selecting blocking factors for getting more capacity out of tape?

[mattfletcher]

hey, this works great as a single command, but when i put it in a script i get

./dsbackupc: line 18: unexpected EOF while looking for matching ``'
./dsbackupc: line 19: syntax error: unexpected end of file

Which is a little perplexing for me

my script is fairly simple

#!/bin/sh
killall rsync
sleep 10
MOUNTPOINT="/IBMraid"
if mount | awk '{print $3}' | grep "^$MOUNTPOINT$" > /dev/null ; then
echo "Mounted OK"
else
echo "$MOUNTPOINT is not mounted"
exit 1
fi
cd /IBMraid ; echo Starting new job at: `/bin/date` > /var/log/dsbackuplogs/dsbackup
echo Completed at: `/bin/date` >> /var/log/dsbackuplogs/dsbackup.log
tar cfz "dsbackup_`date '+%d-%m-%Y'`".tgz /var/log/dsbackuplogs/dsbackup.log

can anyone see anything wrong with this?

[ken_yap]

Somewhere you have a unclosed quote as the error message says. Eyeball your script carefully and make sure you have used single quotes and backticks correctly. You can also use the bash construct $(command args) instead of `command args`. If you do this, change the first line to #!/bin/bash to make sure you get the bash shell, even though it normally /bin/sh is a link to it.