example log :
http-8888-Processor24, 05-Jan-2005 09:43:20, unauthenticated, OPTIONS, 200 "OK", 601 ms, /
http-8888-Processor25, 05-Jan-2005 09:43:21, unauthenticated, PROPFIND, 207 "Multi-Status", 100 ms, /
http-8888-Processor24, 05-Jan-2005 09:43:23, unauthenticated, OPTIONS, 200 "OK", 4 ms, /files/
http-8888-Processor25, 05-Jan-2005 09:43:23, unauthenticated, PROPFIND, 207 "Multi-Status", 32 ms, /files/
http-8888-Processor24, 05-Jan-2005 09:43:26, unauthenticated, HEAD, 404 "Not Found", 14 ms, /files/tf-a01.xml
http-8888-Processor25, 05-Jan-2005 09:43:26, unauthenticated, PUT, 201 "Created", 502 ms, /files/tf-a01.xml
09:43:27,236 DEBUG [no.gan.slide.search.XMLIndexer.updateIndex] Update index for Uri=/files/tf-a01.xml
09:43:27,238 DEBUG [no.gan.slide.search.XMLIndexer.createIndex] Create index for Uri=/files/tf-a01.xml
http-8888-Processor25, 05-Jan-2005 09:43:27, unauthenticated, PUT, 201 "Created", 15964 ms, /files/._tf-a01.xml
09:43:43,245 DEBUG [no.gan.slide.search.XMLIndexer.updateIndex] Update index for Uri=/files/._tf-a01.xml
09:43:43,247 DEBUG [no.gan.slide.search.XMLIndexer.createIndex] Create index for Uri=/files/._tf-a01.xml
http-8888-Processor25, 05-Jan-2005 09:43:43, unauthenticated, PROPFIND, 207 "Multi-Status", 36 ms, /files/._tf-a01.xml
http-8888-Processor25, 05-Jan-2005 09:43:43, unauthenticated, PROPFIND, 207 "Multi-Status", 32 ms, /files/tf-a01.xml
Here im using macosx goliath to upload a xml file into /files, the file i upload is tf-a01.xml and as you can se goliath is tagging on a ._tf-a01.xml file of 82 bytes. The reason i can't just remove the file during transaction is the last two PROPFINDs that looks for both the original and the metafile.
I do fully agree that the osx driver should store this as props, binary even. The problem should perhaps be addressed to osx clients as the version of goliath i got is a bit inconsistent of its usage of the ._metafile. Upon store/retrieve it will perform a matching request for the metafile, but if i select a original file and delete it the metafile remains in the slide store. To filter out these files and store them separately is a great idea but requires a lot of work i guess. And the hetro-env will have the same problem that if a non osx user deletes, moves or access assigns a file, the metafile will be left behind.
A optional and perhaps agent-identifying filter would be best as in a homogenous osx env it would be nice to keep the metafiles, same applies to Thumbs.db, emacs "~" and ".#" files and other kinds of metadata.
hmmm, back to the tinktank
Mvh Karl �ie
On 5. jan. 2005, at 03.40, Carlos Villegas wrote:
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:
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
- you are what you eat. Avoid fruits and nuts...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
