[X-Unix] Panther "Archive" from command-line?

[Scott J. Kramer]

--On Friday, July 16, 2004 15:44 -0400 Stephen Jonke <sjj_public at mac.com> 
wrote:

> "open" is dependent on the GUI and will have the same window server
> issues as BOMArchiveHelper, because it uses BOMArchiveHelper.

Exactly, and I thought you wanted a suggestion that didn't rely on the
GUI.  Using hdiutil and disk images is another possibility.

> Also it's possible the currently logged in user has something other than
> BOMArchiveHelper as the default application for .zip files.

Good point.

> I will try ditto.

Works great when its limitations aren't a factor.

A minor warning if you're seriously considered about data integrity:

When "archive cloning" home directory hierarchies with ditto a few months
ago I noticed a peculiar permissions problem with a couple files even
though the files appeared to be owned and readable/writable by me.  I'm
not sure if it was during creation or restoring but the resources forks
weren't readable (writable?) but using sudo to create (or restore?) the
archives avoided the problem.

There's a way files originally created while authenticated will look like
they're owned by a non-authenticated user when running non-authenticated,
but will appear to be root-owned when authenticated.  For instance:

  % ls -l
  total 128
  -rw-r--r--  1 me   unknown  61636 17 May 19:52 Macintosh HD Report.pdf

  % sudo ls -l
  total 128
  -rw-r--r--  1 root  unknown  61636 17 May 19:52 Macintosh HD Report.pdf

I understand how that can happen but don't have a concise explanation
(yet).  Just wanted to mention it since I suspect it was the reason
behind the resource fork snafu with ditto mentioned above and can have
similar permission-related side effects with other programs depending
on their authentication context.

-sjk