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