Re: Re: can dar handle Mac resource forks

Paul Tremblay <[email protected]>
Newsgroups gmane.comp.sysutils.backup.dar.general
Message-ID <[email protected]>
On Wed, Jan 12, 2005 at 10:30:10PM +0100, Denis Corbin wrote:
> Paul Tremblay wrote:
> | Can dar handle resource forks in the Macintosh file system? A resource
> fork is data
> | that is
> | bundled along with the regular file. Traditional archivers like tar
> cannot handle
> | them. (A
> | hack was invented for pax, called hfspax, which can handle these
> resoure forks.)
> 
> I suppose you mean "resource forks" and "finder informations" (beside
> the "data forks") ? This is a feature request that is not straight
> forward to add properly in dar. For a given file, dar already handle the
> inode information (file ownership, permissions, dates and so on), the
> data (=data forks) and the Extended Attributes (when the filesystem
> supports them). While all theses are common to many Unix filesystem
> (ext2fs, ufs, minix (excluding EA), ...) the file forks are very
> particular to Macintosh hfs filesystem which is not really a Unix
> system, isn't it ?
> 
> By the way, have you succeeded running dar under Macintosh ?


> 
> macOS X is a Unix like system and does not seems to use file forks, am I
> wrong ?

mac OS X still uses resource forks. For example, the quicken program,
quite popular, uses them, and without them will not work. I also think
MS word uses them. However, unlike quicken, MS Word will work without
resource forks. 

Yes, resource forks are unique to the Macintosh file system. Eventually,
Macintosh plans to phase them out, but in the mean time they are quite
crucial. While *most* files will get restored without resource forks, a
small percentage will not.  

Frankly, these resource forks are a pain in the neck. I don't fault dar
in any way for not handling them.  However, you might want to post a
message somewhere letting users know that dar cannot properly back up a
Macintosh file system. Even knowledgable people don't know about
resource forks, and might be under the mistaken assumption that they
have backed up their data with dar. For example, in November someone
posted a message to this mailing list saying that they had compiled dar
under Panther. I wonder if that poster is aware of the resource forks
problem?


> 
> |
> | If these resource forks do not get copied to the archive many files
> will be useless.
> |
> 
> yes, in particular executable files.
> 
> 
> | Also, I was wondering about how dar handles compression. My impression
> is that one
> | should
> | not use compression when using an archiver like tar, since one little
> bit of corruption
> | in the
> | archive, and the whole archive is useless. Other archivers like afio
> handle compression
> | much
> | better and are considered safe to use.
> 
> you can find a detailed explaination here:
> http://dar.linux.free.fr/#feat
> reading the "compression","direct access" and "Archive Testing" paragraphs

Thanks. I'll check this out. I have not suceeded yet in compiling dar
under Mac OS X. I tried compiling it under system 10.2 (as opposed to
10.3), and had a little better luck, but the configuration process
stopped when it couldn't find the bzlib. I found a copy of the bzlib on
fink (a repository for Mac OS X software), but hadn't gotten around to
downloading it. At this point, I probably won't try to compile dar for
Mac since it won't handle resource forks. I'll contnuing using hfspax, a
variant of pax which does handle them.

Thanks for your response.

Paul

-- 

************************
*Paul Tremblay         *
*[email protected]*
************************


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.