The problem is that webdav has been implemented as a full fledge filesystem in osx, so osx treats it like that. I have experimented with slide and osx and slide happily stores the metafile so a file placed in slide and downloaded again will keep its custom icon and other osx-meta-info witch is great.
Problem is that this is very confusing for hetrogenous deployment as osx users fills up the store with metafiles, and windows users removes or updates only the original file. Perhaps they will access-assign or move the original file without moving the osx metafile.
So yes, even if this criples osx functionality its not critical to lose these files when the slide is to store only xml documents and other plaintext files.
Sadly i cannot as the customers users to disable(if possible) this feature of osx as when it comes to executables and other binaries the metainfo might be the only way to get...eh.. metainfo from the file.
Still i think it would be usefull to apply some kind of go-away-filter on a slide store so files like this could be filtered out without freaking out the user. Come to think of it i might work with extending the filter i made to block these files to also always reply a webdav OK and a empty stream for any request that matches this pattern. hm....
Thanks for brainstorming me here!
Karl �ie
On 4. jan. 2005, at 18.12, Warwick Burrows wrote:
- Bush's national security adviser Condoleezza Rice sounds like a mexican side dish.
Karl,
I don't want to sound negative but this sounds like a very difficult problem
to solve since its your webdav client, mac os x, that wants to put the "._"
files in there and expects them to be there when it requests them. If they
do contain metadata then it suggests that mac os x will want to see it or
update it at sometime. So if you do fake the files existence in Slide how
will you fake the metadata content when mac os wants to see the contents of
the "._" file, or modify it?
Alternatively, if these metadata files are entirely unecessary and mac os x
doesn't use them for anything once they are created (except to check they
exist) then are they a defunct feature of the os and can the feature be
disabled with an os or filesystem configuration setting?
Warwick
-----Original Message----- From: Karl �ie [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 04, 2005 3:26 AM To: Slide Users Mailing List Subject: Re: blocking/removing unwanted files
know thatYou mean you implemented a event ContentListener that throwed a VetoException on creation of those files and it didn't work? Or just removed the files afterwards so the client doesn'tthey are not there anymore.
Tried both, the last option works, but gives the user an error when uploading even as uploading succeeds, and i dont want that, so what i am trying now is to silently remove the item behind the back of the user. The problem is that macosx does a propfind on the "._blahblah.blah" files too and if it cant find it it reports an error to the user.
My desperate thought is to kill the "._" file at uploadtime, and then fake a OK propfind on it, but that is really a dirty hack solution. Any alternatives is appreciated.
Mvh Karl
On 4. jan. 2005, at 03.05, Carlos Villegas wrote:
Karl �ie wrote:with macos-xHi there, just started out with slide so this might be a newbie question but i found nothing trying to search the lists. I am setting up slide in a pc/mac env and i have problemrepositorypolluting the store with files starting with "._". As much as i understand these are osx metafiles i dont want them in thefiles startingand not versioned. How can i block these? a: I've tried: to write a servlet filter that ignoresmetafiles andwith "._" and placed it infront of the webdav servlet, no go. OS-X gives me webdav error because it cant find the dam "._" files it tries to store together with the real files. b: Ive tried a ContentInterceptor that tries to filter out these files, but i get the same problem, OS-X asks back theknow thatgives and error because they have been removed by the interceptor.
You mean you implemented a event ContentListener that throwed a VetoException on creation of those files and it didn't work? Or just removed the files afterwards so the client doesn'tthis? Mvhthey are not there anymore.
Does anyone here got any good idea about how to deal with---------------------------------------------------------------------Karl - you are what you eat. Avoid fruits and nuts...
---------------------------------------------------------------------To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
- Somewhere, out there on the Net, is an HD full of lame quotes
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
