You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Charles Brooking <pu...@charlie.brooking.id.au> on 2009/05/15 08:52:26 UTC
WebDAV from Mac
Hi all
I'm running the Jackrabbit WebDAV servlet
(org.apache.jackrabbit.j2ee.SimpleWebdavServlet) and am currently
wrestling with the quirks of the Mac client. This has been mentioned
previously on the list: basically, if you upload a file 'foo.img', it will
create that file without any content, create another file '._foo.img' and
populate it with content, then *fail to* copy the contents from
'._foo.img' to 'foo.img' and delete '._foo.img'. The failure to copy
content means that only a zero-byte file remains.
Before I go and further debug things, is this a known problem?
I have performed an upload while running a simple event listener that just
outputs every event that happens. This might help people wanting to
understand things (and save them from running the experiment themselves).
I've added comments, particularly at the end where things totally break.
// Create foo.img file
[PROP_ADDED ] at /files/foo.img/jcr:content/jcr:lastModified
[PROP_ADDED ] at /files/foo.img/jcr:content/jcr:mimeType
[PROP_ADDED ] at /files/foo.img/jcr:content/jcr:data
[PROP_ADDED ] at /files/foo.img/jcr:content/jcr:primaryType
[NODE_ADDED ] at /files/foo.img/jcr:content
[PROP_ADDED ] at /files/foo.img/jcr:primaryType
[PROP_ADDED ] at /files/foo.img/jcr:created
[NODE_ADDED ] at /files/foo.img
// Create ._foo.img file
[PROP_ADDED ] at /files/._foo.img/jcr:content/jcr:lastModified
[PROP_ADDED ] at /files/._foo.img/jcr:content/jcr:data
[PROP_ADDED ] at /files/._foo.img/jcr:content/jcr:mimeType
[PROP_ADDED ] at /files/._foo.img/jcr:content/jcr:primaryType
[PROP_ADDED ] at /files/._foo.img/jcr:created
[PROP_ADDED ] at /files/._foo.img/jcr:primaryType
[NODE_ADDED ] at /files/._foo.img/jcr:content
[NODE_ADDED ] at /files/._foo.img
// Add data to ._foo.img file
[PROP_ADDED ] at /files/._foo.img/jcr:mixinTypes
[PROP_ADDED ] at /files/._foo.img/jcr:lockIsDeep
[PROP_ADDED ] at /files/._foo.img/jcr:lockOwner
[PROP_CHANGED] at /files/._foo.img/jcr:content/jcr:lastModified
[PROP_CHANGED] at /files/._foo.img/jcr:content/jcr:data
[PROP_REMOVED] at /files/._foo.img/jcr:lockIsDeep
[PROP_REMOVED] at /files/._foo.img/jcr:lockOwner
// Add data to .DS_Store file
[PROP_ADDED ] at /files/.DS_Store/jcr:lockOwner
[PROP_ADDED ] at /files/.DS_Store/jcr:lockIsDeep
[PROP_CHANGED] at /files/.DS_Store/jcr:content/jcr:lastModified
[PROP_CHANGED] at /files/.DS_Store/jcr:content/jcr:data
[PROP_REMOVED] at /files/.DS_Store/jcr:lockOwner
[PROP_REMOVED] at /files/.DS_Store/jcr:lockIsDeep
// Delete ._foo.img file
[PROP_ADDED ] at /files/._foo.img/jcr:lockIsDeep
[PROP_ADDED ] at /files/._foo.img/jcr:lockOwner
[PROP_REMOVED] at /files/._foo.img/jcr:lockIsDeep
[PROP_REMOVED] at /files/._foo.img/jcr:lockOwner
[NODE_REMOVED] at /files/._foo.img/jcr:content
[NODE_REMOVED] at /files/._foo.img
// Add data to foo.img file? (most times nothing actually happens here:
// jcr:content/jcr:data is not set and resulting files is 0 bytes)
[PROP_ADDED ] at /files/foo.img/jcr:mixinTypes
[PROP_ADDED ] at /files/foo.img/jcr:lockOwner
[PROP_ADDED ] at /files/foo.img/jcr:lockIsDeep
// Expect [PROP_CHANGED] at /files/foo.img/jcr:content/jcr:lastModified
// Expect [PROP_CHANGED] at /files/foo.img/jcr:content/jcr:data
[PROP_REMOVED] at /files/foo.img/jcr:lockOwner
[PROP_REMOVED] at /files/foo.img/jcr:lockIsDeep
Later
Charlie
Re: WebDAV from Mac
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Jun 19, 2009 at 6:45 AM, Charles
Brooking<pu...@charlie.brooking.id.au> wrote:
> A month ago I wrote about how uploads from the Mac WebDAV client were
> mysteriously resulting in 0 byte files. I've revisited this and discovered
> that the problem occurs when using an Apache proxy.
>
> The Mac client sends HTTP messages with a "Transfer-Encoding: Chunked"
> header, but Apache expects "chunked" (lowercase) and decides it isn't
> supported. To make Apache also handle "Chunked", you can use mod_headers:
>
> ProxyPass / http://localhost:8080/
> ProxyPassReverse / http://localhost:8080/
> RequestHeader edit Transfer-Encoding Chunked chunked early
>
> (I think the Mac client is wrong here - although HTTP header names are
> case-insensitive, I don't believe the same applies to header values. In
> any case, this workaround is harmless.)
>
> Hopefully this will help someone.
Thanks for providing this info!
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: WebDAV from Mac
Posted by Charles Brooking <pu...@charlie.brooking.id.au>.
Hi all
> I've had Jackrabbit run successfully with the Mac WebDAV client. Indeed,
> as I try it now, it works. So I'll need to dig deeper to discover the
> problem.
A month ago I wrote about how uploads from the Mac WebDAV client were
mysteriously resulting in 0 byte files. I've revisited this and discovered
that the problem occurs when using an Apache proxy.
The Mac client sends HTTP messages with a "Transfer-Encoding: Chunked"
header, but Apache expects "chunked" (lowercase) and decides it isn't
supported. To make Apache also handle "Chunked", you can use mod_headers:
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
RequestHeader edit Transfer-Encoding Chunked chunked early
(I think the Mac client is wrong here - although HTTP header names are
case-insensitive, I don't believe the same applies to header values. In
any case, this workaround is harmless.)
Hopefully this will help someone.
Later
Charlie
Re: WebDAV from Mac
Posted by Charles Brooking <pu...@charlie.brooking.id.au>.
G'day,
> I too have it running under Mac OSX 10.5.7 with the latest Jackrabbit
> 1.5.5 build.
> If it would be helpful, I'd be more than happy to zip up everything
> including the configuration and send it to you.
> I'm using MySQL for the repository and data store, so you may have to
> change it. Just e-mail me if you want it.
Thanks Robert (and also Alex) for following-up.
I've had Jackrabbit run successfully with the Mac WebDAV client. Indeed,
as I try it now, it works. So I'll need to dig deeper to discover the
problem.
The only complication I have is an EventListener that does processing on
files that are uploaded: because the timing of listeners is variable, this
means the problem could be difficult to reproduce. I have since solved
another problem, though, by waiting for the lock to be released (instead
of just monitoring jcr:data changes) so this could have somehow "fixed"
things. I will try to investigate further when I find the time.
Later
Charlie
Re: WebDAV from Mac
Posted by Robert Morse <rm...@mdesignz.com>.
I too have it running under Mac OSX 10.5.7 with the latest Jackrabbit
1.5.5 build.
If it would be helpful, I'd be more than happy to zip up everything
including the configuration and send it to you.
I'm using MySQL for the repository and data store, so you may have to
change it. Just e-mail me if you want it.
-robert.
On May 15, 2009, at 10:49 AM, Alexander Klimetschek wrote:
> On Fri, May 15, 2009 at 12:52 AM, Charles Brooking
> <pu...@charlie.brooking.id.au> wrote:
>>> Are you using Mac OS X 10.5 integrated WebDAV support (WebDAV FS)
>>> and
>>> are you getting an error message -36 ?
>>
>> I'm using the 10.5.6 "Go > Connect to Server" client, although I
>> don't see
>> any error messages: the files appears to be created but has a size
>> of Zero
>> KB.
>
> The only thing I can say is it works for me. Using 10.5 WebDAV for a
> long time and never had that issue. The only problem I had was when
> there was some repository error, throwing exceptions (I think even
> OutOfMemory) all the time, which lead to weird behaviour in the Mac
> Finder, with folders and files disappearing. Maybe there is something
> specific going wrong in your case that triggers that error, because
> AFAIK there is no general problem with the Mac WebDAV client (as
> compared to the buggy MS Windows webdav clients).
>
> Regards,
> Alex
>
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
The human mind is an iterative processor, it never does anything right
the first time. What it does well is to make improvements on every
iteration (deMarco)
Re: WebDAV from Mac
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, May 15, 2009 at 12:52 AM, Charles Brooking
<pu...@charlie.brooking.id.au> wrote:
>> Are you using Mac OS X 10.5 integrated WebDAV support (WebDAV FS) and
>> are you getting an error message -36 ?
>
> I'm using the 10.5.6 "Go > Connect to Server" client, although I don't see
> any error messages: the files appears to be created but has a size of Zero
> KB.
The only thing I can say is it works for me. Using 10.5 WebDAV for a
long time and never had that issue. The only problem I had was when
there was some repository error, throwing exceptions (I think even
OutOfMemory) all the time, which lead to weird behaviour in the Mac
Finder, with folders and files disappearing. Maybe there is something
specific going wrong in your case that triggers that error, because
AFAIK there is no general problem with the Mac WebDAV client (as
compared to the buggy MS Windows webdav clients).
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: WebDAV from Mac
Posted by Charles Brooking <pu...@charlie.brooking.id.au>.
Hi Cédric
> Are you using Mac OS X 10.5 integrated WebDAV support (WebDAV FS) and
> are you getting an error message -36 ?
I'm using the 10.5.6 "Go > Connect to Server" client, although I don't see
any error messages: the files appears to be created but has a size of Zero
KB.
Later
Charlie
Re: WebDAV from Mac
Posted by Cédric Chantepie <cc...@corsaire.fr>.
Charles Brooking a écrit :
> Hi all
>
> I'm running the Jackrabbit WebDAV servlet
> (org.apache.jackrabbit.j2ee.SimpleWebdavServlet) and am currently
> wrestling with the quirks of the Mac client. This has been mentioned
> previously on the list: basically, if you upload a file 'foo.img', it will
> create that file without any content, create another file '._foo.img' and
> populate it with content, then *fail to* copy the contents from
> '._foo.img' to 'foo.img' and delete '._foo.img'. The failure to copy
> content means that only a zero-byte file remains.
>
> Before I go and further debug things, is this a known problem?
>
> I have performed an upload while running a simple event listener that just
> outputs every event that happens. This might help people wanting to
> understand things (and save them from running the experiment themselves).
> I've added comments, particularly at the end where things totally break.
Are you using Mac OS X 10.5 integrated WebDAV support (WebDAV FS) and
are you getting an error message -36 ?
--
Cédric Chantepie
Architecte des systèmes d'information
NOZICAA (Groupe SIGIRE) - http://www.nozicaa.com
20 rue de Sardaigne - Z.A. du Danemark - 72100 LE MANS
Tel: +33 (0) 243 82 97 97
Fax: +33 (0) 243 82 97 99