I've reproduced this problem with a 2.1M1 server. -James
>>> [EMAIL PROTECTED] 6/21/2004 2:11:15 PM >>> I'm really hoping that this has been fixed. I have a bit to add in case it hasn't. > 2 - Some kind of acl corruption, similar to the one described in this mail : > http://www.mail-archive.com/[EMAIL PROTECTED]/msg05618.html : > I set a permission using slide client ( read on /slide/files/test/ to /users/me) and > I display the acl. Everything is OK, inherited permissions are here, and my perm is > not inherited. Then, i do ls /slide/files/test/, it displays the content of test, it's > OK. Then I display the acl one more time : the permission has changed and is now > inherited from /slide/files/test, and the client is unable to delete it. ( it can't > delete a perm inherited from another collection, and the perm is inherited from > itself). I'm seeing the same behavior. If I list the acls for a *collection* using the Slide command line client everything is fine. I can grant/deny/revoke no problem. As soon as I list the acls using the client I wrote (2 lines of code!!!) any acls set on the collection report that they are inherited from the collection. Going back to the command line client I get the same response (acls are inherited). Restarting the Slide server resets the inheritance to what it's supposed to be. The only difference I've been able to see using Axis's tcpmon is that with the client I wrote the client sends a PROPFIND and then an ACL in the same HTTP 1.1 connection. With the command line client the ACL request is by itself. Note, this only seems to happen on collections. I'm guessing this is because files can't have inherited acls. Here's the client code I wrote that causes the inheritance to get confused. public static Ace[] listPermissions( String url ) { try { HttpURL httpUrl = new HttpURL( url ); WebdavResource res = new WebdavResource( httpUrl ); return res.aclfindMethod(res.getPath()).getAces(); } catch ( HttpException e ) { e.printStackTrace(); } catch ( IOException e ) { e.printStackTrace(); } return new Ace[0]; } > 3 - If i try to revoke or grant a permission when the acl is corrupted (using aces = > findAclMethod then aclmethod( aces ) ) All previous permissions are removed. I checked > using eclipse that i call aclmethod with an array containing the same acls that I read > but none of them is used. Same thing using the client. At least I have an answer for this one :). The generateRequestBody() method for AclMethod ignores any aces that are inherited or protected. Since the ACL http method overwrites the existing acl, this prevents a resource from suddenly gaining explicit permissions that are supposed to be inherited. The problem is when the inheritance on the ace gets messed up so that it's inheriting from itself, AclMethod doesn't include this ace when it builds the request body. This means the ace is effectively lost. Somebody please tell me this is fixed. -James --------------------------------------------------------------------- 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]
