Re: Mac OS X WebDAV and mime type question

[Scott Dietrich <sc...@minutestopost.com>]

Hello,

After looking into things a bit more, I realized I was able to  
resolve the issue by overriding doMove in my servlet without making  
changes to AbstractWebdavServlet. I'm including the method here in  
case others are having the same problem with Mac OS X clients.

     @Override
     protected void doMove(WebdavRequest request, WebdavResponse  
response, DavResource resource) throws IOException, DavException {
         if (!resource.isCollection()) {
             String mimeType = getResourceConfig().getMimeResolver 
().getMimeType(request.getDestinationLocator().getResourcePath());
             resource.setProperty(new DefaultDavProperty 
(DavPropertyName.GETCONTENTTYPE, mimeType));
         }

         super.doMove(request, response, resource);
     }

Scott


On Jun 30, 2008, at 12:39 PM, Scott Dietrich wrote:

> Hello,
>
> I've been doing some tests with Mac OS X 10.4 and Jackrabbit's  
> SimpleWebdavServlet. It looks like when many apps on the Mac (I  
> think it affects all apps that use the Cocoa libs for file save  
> operations) save a file the following happens:
>
> * The original file is moved to a backup file name (e.g. "xxx.txt"  
> moved to "xxx~.txt")
> * A temp file ending with ".dat" is created containing the updated  
> file data
> * This ".dat" temp file is moved to the original file name (e.g.  
> "xxx.txt")
> * The backup file is removed (or possibly not, I suppose, based on  
> user preferences)
>
> This is somewhat simplified, there are actually a number of other  
> steps (lock, unlock, etc.) but it gives the general idea.
>
> The problem is that a file will have the correct mime type when it  
> is originally uploaded, but is given an incorrect mime type after a  
> file is saved due to the ".dat" temp file name extension. Also,  
> because a new file is created with the incorrect mime type, none of  
> the text extractors run and the file isn't indexed.
>
> Has anyone else noticed this behavior? If so, what is the best way  
> to work around it?
>
> I've managed to work around the problem by patching the doMove  
> method of AbstractWebdavServlet, however it seems fairly awkward  
> because I need access to private methods and data in  
> AbstractWebdavServlet. There doesn't seem to be an easy way to  
> simply override the method in my own servlet. Is there a policy  
> regarding patches to deal with the quirks of individual DAV clients?
>
> Thanks,
> Scott