Re: MacBinary 4 format
Re: MacBinary 4 format
- Subject: Re: MacBinary 4 format
- From: Mike Fischer <email@hidden>
- Date: Fri, 30 Jul 2004 00:47:15 +0200
Am 29.07.2004 um 07:01 schrieb David Catmull
<email@hidden>:
On Jul 28, 2004, at 11:50 AM, Mike Fischer wrote:
The Panther Finder zip archive format could also be considered
standard, depending on your needs.
Are the details for that available anywhere?
Not sure. I thought it was just standard zip with a certain convention
for storing resource forks and meta data.
Here is the result of a little test I made:
First I created a text file in BBEdit and made sure that it had the
BBEdit State information set. (BBEdit stores its state in the resource
fork. So I now have a file containig both resource and data fork.) The
file had a data fork size of 25,846 bytes and a resource fork size of
1,710 bytes.
After using the Panther Finder to Archive the file I went to the
Terminal and did this:
mac-g4:~/Desktop/Test Finder zip mike$ unzip -lv test.txt.zip
Archive: test.txt.zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
25846 Defl:N 6586 75% 07-29-04 22:45 3f738835 test.txt
0 Stored 0 0% 07-29-04 22:45 00000000 __MACOSX/
1792 Defl:N 233 87% 07-29-04 22:45 5449094e
__MACOSX/._test.txt
-------- ------- --- -------
27638 6819 75% 3 files
So the resource file (and presumably the HFS+ meta data) gets stored in
"__MACOSX/._test.txt". This looks very similar to how resource forks
and meta data are stored on UFS volumes or the iDisk. I wouldn't be
surprised if this is actually a variant of the AppleDouble format. But
I didn't check this out any further.
The zip and unzip tools should be open source I think so that part of
the format should be well defined as well. (Or you could just use the
tools from your app if you need the functionality.)
The word standard seems to imply that something at the receiving end
will know the format. Is that something under your control? If so it
might be easier to define your own format. It's not too hard to do.
My own client will usually be the one downloading/uploading the files,
but since it's HTTP it seems like a good idea to make it work with
other HTTP clients as well. My server is already using HTTP for other
things, so I figured it would be a good choice for file transfers too,
especially since there are ways to do things like resumable downloads.
I agree about the usefulnes of the HTTP (1.1) protocol but that doesn't
really explain what you expect to happen when another HTTP client, say
Safari for example, contacts your server. Should Safari a) download the
file, b) download and unpack the file c) display the file d) do
something entirely different?
HTTP is just a transport protocol. It doesn't say anything about the
semantics of the transported data. That would be done by HTML, XHTML,
MIME and other mechanisms. A Browser usually has built-in knowledge
that data sent with MIME-type (Content-Type) image/jpeg is a JPEG file
for example, or that application/x-stuffit is a stuffit archive that
can be decompressed using StuffIt Expander. If you send something the
browser doesn't know about then the best you can hope for is that it
will be downloaded as file without any further action being taken. That
is the data stream is simply saved in a file.
That takes us back to your definition of standard or to what exactly
you mean by "make it work". A standard format that is not commonly
known to a browser will not help you much unless of course I am missing
something vital in your goals.
Mike
--
Mike Fischer Softwareentwicklung, EDV-Beratung
Schulung, Vertrieb
Web: <
http://homepage.mac.com/mike_fischer/index.html>
Note: I read this list in digest mode!
Send me a private copy for faster responses.
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.