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

"Michael C. Macaluso" <email@hidden> wrote:

>A reference to the AppleDouble file format can be found at:
>
> users.phg-online.de/tk/netatalk/doc/Apple/v2/AppleSingle_AppleDouble.pdf

Thanks for the reference.


> Larry, I believe that an AppleDouble-based AFP package is available on
>Linux (Netatalk), so you may be able to accomplish what you want by
>referencing the files via mounted afp volumes (see ditto - I just found
>out about this recently) and the use of file-based URLs. It is not ideal,
>but it may accomplish your tasks if you are doing something quick and
>dirty.

I don't think this will solve the problem, or not solve it any better than
MacBinary (modulo the MacBinary limitations). Also note that AppleSingle
has size limitations (no chunk larger than 4 GB) similar to MacBinary.

He still needs to stick together the data-fork, res-fork, and metadata and
upload the result to a server. If that's in MacBinary or AppleSingle or
AppleDouble or whatever, it still must be done on the Mac OS X system that
is uploading the original file to the server.

The server must then be able to take that transfer-format apart (decode
it), operate on the constituent elements, and put it back together in a way
that a Mac OS 9 user can:
(a) easily decode the downloaded data.
(b) just double-click the decoded file.

If that can be done without deploying and running an AFP service
(netatalk), then that would seem to have the lower impact on the server.

-- 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.