Are these metadata files very big?
A better solution would be to put some kind of filtering mechanism that stores these files as webdav properties. So they remain with the owner file even when handled by other platforms. Then for the osx client, they are exposed again as files. But I'm not sure if this can be done currently, it may require changes in the store or other parts of Slide. Actually, this is what the osx webdav file system driver should do transparently on the client side. The same applies to the Thumbs.db files on Windows for folders that contains images but that's not as problematic.
Carlos
Karl �ie wrote:
Yes its a bit of a problem, macosx uses these files to apply properties like icons, access and other osx-spesific stuff. But the stuff isnt critical since for all files that doesnt have a ._blah.blah file osx tries to create one by guessing the type of the file and applying defaults. This i am sure of, else wise osx couldnt download any files from the internet without also getting a ._ file for it. And the system is much better than macos9 systemfork that was injected into the file itself.
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
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't
know that
they 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:
Hi 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 problem
with macos-x
polluting the store with files starting with "._". As much as i understand these are osx metafiles i dont want them in the
repository
and not versioned. How can i block these? a: I've tried: to write a servlet filter that ignores
files starting
with "._" 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 the
metafiles and
gives 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't
know that
they are not there anymore.
Does anyone here got any good idea about how to deal with
this? Mvh
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
