Bug in hfstar

[Tim Hewett]

Hello,

I'm looking to report a bug I've found in hfstar. If you use
the gzip or bzip2 compression options but send the output
to stdout, i.e. "hfstar cfz - files > archive.tar", extra bytes get
added to the end of the file compared to doing
"hfstar cfz archive.tar files" or "hfstar cf - files | gzip" (the
same applies to the bzip2 option). When you come to
restore the archive you get an error from gzip or bzip2
that there were extra garbage bytes at the end of the file.
If the "differences" mode of hfstar is used, i.e.
"hfstar dfz - files < archive.tar", the error causes hfstar
to exit with a non-zero value, which means my program
can't tell if the diff was successful.

I have a workaround which is to have hfstar not compress
the archive when it is created, but to explicitly pipe the
archive through gzip. I thought you might want to know
about the bug though.

I have a suggestion as well: the point of hfstar is to archive
the HFS resource fork information as well as the data fork.
There is a problem however, which is "what happens
when such archives are restored to non-HFS filesystems?".
If you use the OS X Finder to copy HFS+ files to a non-HFS+
filesystem, e.g. a UFS one, Apple sole the problem by
placing the data fork data in a file with the same name as
the original one, and the resource fork data in a file with
the same name but with "._" at the start. When the file is
dragged back to an HFS+ volume, the resource and data
fork info are reinstated as they were originally. It would
be nice if hfstar were to do that too.

Finally, I am currently using and distributing hfstar as part
of my shareware application DV Backup (see
http://www.coolatoola.com). In the credits section I am
giving a link to the hfstar source and binary downloads
page. I am not distributing the source itself. Is that
satisfactory?

Yours sincerely,

Tim Hewett, Coolatoola.com