[jira] [Commented] (COMPRESS-281) Archives don't contain resource fork on Macs

["Simon Spero (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COMPRESS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16056488#comment-16056488 ] 

Simon Spero commented on COMPRESS-281:
--------------------------------------

Things changed so that now this info is stored as an xattr, with the legacy "..namedfork/rsrc" being just another attribute.  Before,  extended attributes were stored as a special fork. 

In <sys/xattr.h>
{{#define XATTR_RESOURCEFORK_NAME   "com.apple.ResourceFork"}}

The MacOS  release of openjdk doesn't an extended attribute (UserDefined) file view.  An implementation would be quite similar to the Linux version; however, no-one has added it since JDK 7 came out;  support isn't included in JDK-9 either.  You could implement the required code, and write a shim around default FileSystemProvider to do the extra attribute wrangling. 

The default provider can be replaced using the mechanism discussed in [FileSystems::getDefault | https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileSystems.html#getDefault()], which requires setting a system property.  This probably has to be done on the command line, since by the time any user code is executed the default file system will probably have been instantiated.  Note that the value of the property can be a list of classes;  these will be instantiated in the order in which they are given.   Each instance will be passed as an argument to the next, with the first class being passed an instance of the system default classloader;  the final class will become the actual default.  

The wrapper implementation  delegate most methods to the passed in provider. The obvious places where changes are needed
are in the attribute related methods.  The wrapper also needs to create a mostly delegating instance of FileSystem, with changes to return the right provider and add "user" to the list of supported file views. 

 It probably also needs to provide an implementation of UserDefinedFileAttributeView, and some native code to invoke the appropriate system call.

The Linux implementation, which needs a few  extra system call wrappers in its Dispatcher:
 [LinuxUserDefinedFileAttributeView.java|http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/e03f9868f7df/src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java] which relies on a few NIO methods in 
 [LinuxNativeDispatcher.c| http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/e03f9868f7df/src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c#l83 ] 

Or the Solaris implementation, which uses a solaris-specific flag  - the jdk 8 sources are a little solaris biased, as you may have spotted from the url path. 

[SolarisUserDefineFileAttributeView.java|http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/e03f9868f7df/src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java]

This is probably a bit out of scope. 


An alternative disgustingly hacky approach would be to use /usr/bin/xattr, which can make the system calls, and can read/dump the contents of an attribute in hex. Did I mention that /usr/bin/xattr is a python script?  Feel the performance flow through you.

> Archives don't contain resource fork on Macs
> --------------------------------------------
>
>                 Key: COMPRESS-281
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-281
>             Project: Commons Compress
>          Issue Type: Wish
>            Reporter: Dimple Rohara
>            Priority: Critical
>
> Currently, we are able to create archive on windows. But for Mac,it doesn't save the resource fork information. I wish there was more compatibility among the archives created on different Operating systems and could be used easily cross-platform.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)