Re: empty public/Enterprise public/Contacts foldersafter changing permissions on contacts

[email protected] wrote: 
> > I changed permissions on enterprises and companies, so that all 
companies 
> > now have permissions set for all intranet and ogoroot specifically, and 
it 
> > is allowing all.
> > I mounted the filesystem using davfs2 on a linux box, before that 
permission 
> > change, the Enterprises folder  and the Contacts folder were full of 
vcards.
> 
> So this is more of a ZideStore than an XML-RPC question... :)
is there a zidestore m/l?
> 
> > I had zidestore in debug mode 
> > (/usr/local/sbin/ogo-zidestore-1.5 -SoOFSDebugAuthLookup 
> > YES -SoObjectDAVDispatcherDebugEnabled 
YES -SoSecurityManagerDebugEnabled 
> > YES -DAVParserDebugProp YES), when I did an ls -l public/Enterprise see 
the 
> > logs at the end. I cannot see any problem. Shouln't it come up with a 
list 
> > of vcards in that folder?
> 
> Depends on the public/private flags of the Enterprises, I believe.  I
> think that is all the folder hierarchy cares about.  The exact SQLs used
> to enumerate each folder is documented in the latest WMOGAG in the
> ZideStore chapter (have I published that version yet?).
> 
> > Further, I connected with konqueror, using webdavs://....
> > The same URL that I used when mounting with davfs2, and the directories 
were 
> > full with contacts. any idea what my problem could be?
> 
> First; davfs2 and wdfs are, IMO, both quite broken.
I guess this seems to be the problem ;)

> 
> It could be a user-agent issue if the same folder is showing content
> under one client and not another.
> 
> I assume this request below was from Konqueror (the client that showed
> content) and the davfs2 response was empty.  Personally I like to test
> with "curl", then cadaver, if both of those seem OK it must be a client
> issue.
no, this was from the davfs2 request.

> 
> > fetchspec: <EOFetchSpecification[0x0xff1e38]: 
> > entity=/zidestore/so/ogoroot/public/Enterprises/ hints:attributes=(
> >     "{DAV:}displayname",
> >     "{DAV:}getetag",
> >     "{DAV:}getcontentlength",
> >     "{DAV:}creationdate",
> >     "{DAV:}getlastmodified",
> >     "{DAV:}resourcetype",
> >     "{http://apache.org/dav/props/}executable"
> > ),scope=flat+self>
> ...
> > Jul 25 16:35:27 ogo-zidestore-1.5 [4242]: [obj-dav-dispatch]   propfind 
> > result: <SxMapEnumerator 0x1395a88>
> > 192.168.8.195 - - [25/Jul/2008:16:35:27 
> > GMT] "PROPFIND /zidestore/so/ogoroot/public/Enterprises/ HTTP/1.1" 207 
> > 1235186/314 0.648 - - 13M
> 

> Looks like the client got data from this request.  If one shows content
> and the other not then enable stream logging and lets compare the
> requests.   
yes , with -WODontZipResponse YES -WOHttpAdaptor_LogStream YES
I see all the contacts coming, looking the same, as when I do an ls on the 
Accounts folder. 
need to dig more on the davfs2 side for problems.

> 
> I've thought about a user agent hack so that wdfs/davfs2 get the objects
> 'true name' as the displayname since they both use [incorreclty, IMO]
> the displayname as the "filename" which is pretty horrible.
IIRC, the filenames are the same using konqueror too.

> 
> BTW, has anyone tried the new GNOME vfs layer with ZideStore yet?
nope.
> 


thanks
Sebastian

-- 
OpenGroupware.org XML-RPC
[email protected]
http://mail.opengroupware.org/mailman/listinfo/xmlrpc