Re: Possible WebDAV bug?
Re: Possible WebDAV bug?
- Subject: Re: Possible WebDAV bug?
- From: Evert|Rooftop <email@hidden>
- Date: Thu, 26 Feb 2009 13:33:37 -0500
On 26-Feb-09, at 12:37 PM, Jim Luther wrote:
Evert,
* Is there any advice you can give me around submitting resource
forks that are considered 'safe' with finder and will effectively
stop the endless requests? Is there a better way altogether to get
around this?
* What's the best way to get finder to pick up a .VolumeIcon
Apple's WebDAV file system works with most WebDAV servers that act
like file servers, but there's nothing in the WebDAV spec that says
a WebDAV server has to act like a file server just as there's
nothing in the HTTP spec that requires an HTTP server to only serve
up resources a web browser can use. There are many WebDAV servers
that don't act anything like a file servers, and others with
restrictions that ensure they cannot be used as a general purpose
file server (like the filename restrictions imposed by MS SharePoint
servers).
So, if you'd like your WebDAV server to be a general purpose file
server, you're going to have to reset your design goals and
understand that a file server cannot decide what filenames it likes
or dislikes, or what data it will or will not store. That means that
every PUT has to create a resource that the client can expect to GET
(unless of course another client DELETEs it but having the server
automatically delete resources would be like your computer's OS
deciding to delete files you saved). That also means that PUT(x)
must equal GET(x) -- whatever bytes (the "x") are PUT to a resource,
when you GET the same resource you must receive the exact same bytes
back.
My solution is actually to intercept these files (along
with .DS_Store, and temporary files from editor such as vim and
smultron) and place them in a separate directory structure. A cron-job
removes files older than 24 hours.
This has worked quite well; but that left me with a very high amount
of requests to the requests to the resource forks (resource fork is
the correct terminology right?). While experimenting reducing these,
this has been my solution:
* a request to a ._ file is made
* if it exists in the temporary file structure, serve that
* otherwise serve a default
Although I wasn't completely happy with this 'hack', it works quite
well. It turns out Finder (or the webdav filesystem) only keeps on
hammering when it gets the 404, if there's a (possibly invalid) ._
file already, it stops after the first 2 or 3 requests.
If there's ways to trick the filesystem to stop requesting these in a
different way, I'd be all over it though :).
* Finder also seems to ask for the 'appledoubleheader'. Can I get
around the issue altogether using this property? I couldn't find
any documentation around this property.
The "._" files are mostly just AppleDouble Header files. If you
search for "AppleSingle/AppleDouble Formats for Foreign Files
Developer's Note" on the internet, you can find old documentation
for the AppleDouble format. You MUST NOT try to create the "._"
AppleDouble Header files you see Mac OS X create yourself... they
don't exactly follow the old documentation and we reserve the right
to change the file format at any time.
As for the appledoubleheader property, you can safely ignore it. It
is an undocumented optimization between the WebDAV file system and
Apple's iDisk servers. The purpose of the appledoubleheader property
is to get the AppleDouble Header file data along with the other
properties when the AppleDouble Header file contains ONLY the
AppleDouble file header with the 2 entry descriptors and the Finder
Info entry. In that case, the "._" will always be exactly 82 bytes
in length.
I'll definitely take a look at the source. I'd love to attempt to
leverage this optimization as well. I guess I might be able to answer
this myself by looking into the source, but would you happen to know
how I can 'trick' Finder into thinking I do support the appledouble
header and it's 'ok' to ask for these/write them when needed? I don't
think I'm able to get a trial account for iDisk anymore without
entering credit card information; so the source code would be my only
hope after that :)
Thanks very much for helping with this, your responses are very much
appreciated!
Evert
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden