Re: Possible WebDAV bug?
Re: Possible WebDAV bug?
- Subject: Re: Possible WebDAV bug?
- From: Jim Luther <email@hidden>
- Date: Thu, 26 Feb 2009 09:37:51 -0800
Evert,
One of the (somewhat) annoyances I've had with Finder is the sheer
number of requests.
It's not just the Finder... it's all applications. We're constantly
amazed by the number of redundant file system calls by all
applications, libraries and frameworks. Run the Mac OS X fs_usage tool
(sudo fs_usage -f filesys) if you want to see what I mean.
The WebDAV file system goes to great lengths to cache everything it
gets from the server and to keep the cache for times longer than most
other network file systems running on LANs would keep a cache (for
example, the information returned by stat is kept in the cache for 60
seconds). When I worked on the WebDAV file system, most of my time was
spent looking at transactions with the server and figuring out ways to
reduce their number while still working correctly as a file system.
* 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.
* 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.
And as Alan Shouls correctly pointed out, you can look at the WebDAV
file system's source code.
- Jim
On Feb 26, 2009, at 8:15 AM, Evert|Rooftop wrote:
On 25-Feb-09, at 9:42 PM, Jim Luther wrote:
Hope that helps :-)
- Jim (I haven't worked on the WebDAV file system since Tiger) Luther
Hi Jim,
Thanks for the great response.. This allows me to dig a little
further into the problem.
I have another issue I would love to get your feedback on..
The WebDAV implementation I'm writing is supposed to be a front-end
for a database. One of the (somewhat) annoyances I've had with
Finder is the sheer number of requests. I wrote some of my notes
down here:
http://code.google.com/p/sabredav/wiki/Finder
Because it's supposed to serve as database front-end, I needed to
intercept all resource forks PUT's and GET's. I initially started
off by just sending back 403 and 404's for these.
This seemed to put finder in a loop, endlessly trying to find the
resource forks. My solution has been to send back a standard
resource fork for every request.
On top of that, I'd like to show a Volume Icon. As far as I can
tell, this requires some flag in the root (._.) resource fork.
Ideally I would not want to make any guesses or hacks around this,
and simply generate appropriate resource forks when requested.
So my questions:
* 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?
* 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.
* What's the best way to get finder to pick up a .VolumeIcon
I know these are a lot of questions, but if you could help me in any
way I'd be very grateful! I will definitely document all my findings
for the benefit of other developers :)
Evert _______________________________________________
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
_______________________________________________
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