Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony Hoyle wrote: >> First comment is that the form the parameters get passed to the command >> doesn't lend itself well to routing calls to cvs through a batch file. >> The batch file interprets the comma (as in "-a read,write") as >> parameter separator and passes this on with a space (as in "-a read >> write"). Not sure that is relevant for many, but it's for me... > > What kind of batch file? AFAIK cmd.exe doesn't behave like this. You're right. It occurred to me to test this after I sent the message. 4NT does what I said above, but cmd.exe works well. >> Secondly I have a question about the recursiveness. The manual says that >> the ACLs are recursive; that is, the effective permissions in a given >> directory are the overlay of all permissions set in all parent >> directories. Yet it seems that the command (r)lsacl returns only the >> permissions set for the particular directory it gets called for > Pretty much, but then it's never going to be complex normally.. you might > have a global setting at the root, then one per module. Less often > directories within that would have special ACLs.. even then that's only > 3 layers. That's right. But wouldn't it be more logical if (r)lsacl would actually list the access permissions for a module? If I want to know whether the permissions are ok or whether I need to change anything, I'm not at all concerned with what's set in a particular module, I'm concerned with what is /valid/ in a particular module. The current behavior of (r)lsacl doesn't seem to be of much use to me (other than that it provides the possibility of manually overlaying the parent permissions). This also would avoid any mistakes on my side with the manual overlay: I'd simply get returned the permissions the server will use. > Owners are set by chown/rchown, and automatically by add/import. They appear to get set by chacl, too. At least I had a number of cases where there was no owner (as shown by lsacl) after the server update, but I was the listed owner after a chacl command. Gerhard