SourceForge has been redesigned. Learn more.
Close

#18 Resource forks are always excluded

open
nobody
Mac SDK (2)
5
2010-08-30
2010-08-30
Lane Roathe
No

This is a serious bug, as I just found that hundreds of backups I have done are no worthless.

What I just discovered is that Keka is always excluding the resource fork (actually, any non-primary fork) in archives, regardless of the "Exclude Mac resource forks" option (which, as reported in <a href="https://sourceforge.net/tracker/?func=detail&aid=3056263&group_id=275361&atid=1169895">issue 3056263</a> is improperly named for it's functionality).

For Keka to be useful on a Mac OS X system for archiving, it needs to be able to archive and restore all forks a file contains. (A file can contain one or more forks, and not necessarily have either a data or resource fork).

It would be good to have "Exclude Mac resource & other non-data forks" option still, as sometimes you do want to archive only the data forks, such as when sending a document to a Windows user.

Discussion

  • aONe

    aONe - 2010-09-06

    I can't reproduce what you explain. If I check the option to exclude, the files are excluded, if not, they're not excluded. Wich version are you using?

     
  • Lane Roathe

    Lane Roathe - 2010-09-06

    This issue doesn't have anything to do with the option to exclude, although this confusion is a an example of good reason to rename it as you suggest in issue ID 3056263.

    So, assume that option is now named "Exclude hidden system files". Given that, there is nothing in Keka to designate whether or not to include or exclude non-data forks in files (the most common non-data fork of course being the resource fork), and at the moment the default is to exclude.

    To summarize, this issue is about the fact that Keka only archives the data fork for any file it includes in an archive (regardless of whether or not the exclude option is checked or unchecked), and ignores all non-data forks in those files. The result is that any file that has a non-data fork (most commonly a resource fork) will not be archived correctly.

     
  • aONe

    aONe - 2012-04-12

    This must be fixed in p7zip or 7-zip, which is the binary that does not handle properly the metadata and forks.

     
  • Lane Roathe

    Lane Roathe - 2012-04-17

    I don't understand why it must be fixed in p7zip or 7-zip, there are many other compression programs which handle multiple forks and metadata just fine using those binaries.

    It does require walking each fork (data/resource/etc) of a file and passing the open file ref to a library API (vs a separate executable) so each fork compresses as a separate file. Meta data is handled in much the same way. The __MACOSX folder in an archive stores these extra items, where file.ext is the resource fork and .file.ext is the metadata. (Not sure how other forks of a file would be handled, but those should be rare)

     
  • aONe

    aONe - 2012-04-17

    I don't get your point. If you create a tgz or tbz file with Keka (two or more files in gzip or bzip format) you'll see that the forks are handled without trouble. That's cause Keka uses gnutar for that format (compression and extraction).

    Also for backup, 7z man page says that:

    DO NOT USE the 7-zip format for backup purpose on Linux/Unix because : - 7-zip does not store the owner/group of the file.

    I'll use gnutar for tar, gz and bz in the future for a better backup handling.

     
  • Lane Roathe

    Lane Roathe - 2012-04-17

    OK, so you are using external applications vs libraries, which makes more sense about the need to have p7zip/7-zip support forks and metadata.

    However, if you are using gnu tar then you can use the --lzma option to create tar files compressed with the same compression as 7zip (suffix .tlz).

    Perhaps useful as well:

    http://www.gnu.org/software/tar/manual/html_chapter/Formats.html#auto_002dcompress

     

Log in to post a comment.