Re: Possible WebDAV bug?
Re: Possible WebDAV bug?
- Subject: Re: Possible WebDAV bug?
- From: Jim Luther <email@hidden>
- Date: Thu, 26 Feb 2009 10:54:07 -0800
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.
I'll repeat this one more time...
If you want your WebDAV server to act like a file server, you cannot
delete resources you "don't like" for whatever reason. Those resources
were created for a reason and it's not your job to decide if that
reason is valid or not. The .DS_Store files and the AppleDouble files
contain useful information that if deleted will cause part of Mac OS X
or the applications that created those files to not work.
If you decide your WebDAV server won't or cannot act like a general
purpose file server, then don't try to mount it with the WebDAV file
system. Your WebDAV server won't be the first and won't be the last
that doesn't work like a general purpose file server and so doesn't
work with the WebDAV file system.
- Jim
On Feb 26, 2009, at 10:33 AM, Evert|Rooftop wrote:
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 _______________________________________________
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