[
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)
