Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: java file transfer from hfs to non-hfs filesystem and back

Larry Roberts <email@hidden> wrote:

>Problem:
> i need to transfer files using a java client from a os x machine, to
>a linux server, and download via web browser back to the mac, retaining
>the mac specific file information.

The fact that you are originating on Mac OS X, or any Mac OS system at all,
means that you can almost certainly use MacBinary.

One limitation is file-size, as the MB format itself cannot handle files
larger than 2 GB (arguably, 4 GB). This is rarely a significant obstacle,
since most files are smaller. A second limitation of MB is long filenames
or non-Roman alphabets in filenames, which can be worked around. A third
limitation is preserving file ownership and permissions, which the MB
format has no concept of. This also can be worked around. One way is to
store the additional information in a ZIP-file, along with the normal
MB-encoded form of the original file in a sort of meta-MB archive. This
can't solve the huge-files limitation, but 2 out of 3 ain't bad.

You can also just ignore these limitations, depending on how much fidelity
you have to preserve in the encoded form. That is, if you don't have to
encode huge files, preserve long Unicode filenames, or retain ownership and
access permissions, then MacBinary alone will suffice.


>Conditions:
> - java transfer from mac os x to linux
> - i cannot use the MacBinary format because there are file operations
>that need to be performed on the server

No problem, as long as the operations don't involve changing the contents
of the resource-fork. You simply decode the file on the server, save the
res-fork and metadata in some safe parking-place (e.g. a file with a
related derived name), operate on the data-fork, then re-encode using the
new data-fork and the parked res-fork and metadata.

When the server receives a file encoded in MacBinary, all the constituents
of the original file are there for it to operate on. It just happens to be
bundled up in the MacBinary format. As long as you can read and write the
pieces, and reapply the encoding, you can do whatever you want with the
pieces of the original file. Conceptually, this is no more difficult or
non-portable than working with the contents of a ZIP archive, a tar
archive, or any other transfer/storage encoding.

The MacBinary Toolkit handles all these pieces, and you can encode, decode,
or simply read directly from the pieces using an appropriate class:
<http://www.amug.org/~glguerin/sw/#macbinary>

A MacBinaryPiecer lets you read the metadata and both forks on any
platform. The MB-encoded file is simply used as a container, and can be
represented by any RandomRW container, such as RandomRWFile wrapped around
a RandomAccessFile. This does NOT require a FileForker implementation, so
would be appropriate for use on the server.

A MacBinaryEncoder works at a high level with a FileForker, or at a low
level with individual pieces. On the server, two of those pieces are
simply the original metadata and res-fork you've safely squirreled away, or
are obtaining directly from the original MacBinaryPiecer. The data-fork is
the only piece you have to represent anew, and it can be an RandomRW
container, such as RandomRWFile as above. Again, you do not need a
FileForker imp to use a MacBinaryEncoder at this level, so it would be
appropriate for server use.


> - web browser download from linux to mac os x OR os 9
> - i can not do anything to the files once the browser download is
>started - the file(s) are tar.gz'ed before download

The file in the tar archive should be MB-encoded, otherwise the recipient
won't be able to do anything with it.

> - after the download is finished, and the tar.gz is unpacked, the mac
>user must be able to double click the file and have it open with the
>appropriate app without any other operation having to be performed.

All of this is entirely possible with MacBinary and the MB Toolkit.


>My understanding of the situation:
> - the mac specific information is held in the resource fork of the file

Plus metadata.

> - the resource fork information can only be handled by the HFS/HFS+
>file system

False. The resource fork and metadata can be stored in a related file on
other filesystems. On UFS and FAT, Mac OS X uses the "._" naming
convention.

> - when osx transfers a file between hfs and non hfs systems it creates
>a file
> called ._myfile which represents the resource fork info.

Plus metadata.

> - you need to keep this ._myfile together with the data fork myfile

Actually, you need to be able to encode and decode it as appropriate for
the file-system.

The "._" convention is a LOW-LEVEL stored representation of metadata and
res-fork. It is undocumented and subject to change. It is NOT a transfer
format or encoding, which is what MacBinary is.

> - when you transfer this pair of files back to an hfs file system, the
>mac os should use the ._myfile for the resource information.

Plus metadata.


>My current implementation:
> - i have the SplitForks utility from the /Developer/Tools package
> - the java app uses the SplitForks tool (SplitForks myfile) before the
>transfer
> - both files are transferred to the linux server
> - files are tarred and gzipped before download
> - files can be downloaded and unpacked
> - md5 on the downloaded ._myfile and myfile show that they are
>identical
> - mac os does not find any creator/type information

Because the metadata isn't in the res-fork.

One approach would be to use GetFileInfo, but you'd have some parsing to
do. Also, the user would have to have installed the multi-megabyte
Developer Tools, or SplitForks and GetFileInfo won't even exist.

Besides, you'd still have to put the 3 pieces (data-fork, res-fork,
metadata) together in such a way that the eventual recipient, a Mac user
running a Mac OS machine, can decode and use the file. They aren't going
to be able to do anything with 3 separate and distinct chunks of data in a
tar.gz archive, unless it's encoded as MacBinary.

-- GG
_______________________________________________
java-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/java-dev
Do not post admin requests to the list. They will be ignored.



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.