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 firstname.lastname@example.org.
Tony Hoyle wrote: > Essentially files in a directory are usually dependent on each other (in the source case) or related (in the document case). If you have directories where half the files shouldn't be seen then this suggests a reorganisation of the files would achieve the results in a more reliable way. > > If the documents are really that sensitive personally I'd recommend a separate repository, as we do here with our internal stuff. I agree with you here. But I'm dealing with a legacy repository. And my view of a tool is that it should not impose policies just for clarity. > > Internally what happens is the user has a directory they can't properly update.. Either it fails completely or the error messages screw up any frontend they may be using (since most users use a frontend of some sort). This doesn't help their experience much - it would be better for them if they never knew the 'privileged' documents ever existed. This is easily fixed by removing the error messages. ;-) It would even fix the problem of users knowing the names of files they shouldn't read. I have patched cvsnt to do what I said in the last email, except for tag verification. Apparently it solved my problem. I'll add tag verification soon. Do you want to receive a copy of the patches? ... What I really miss is an option to control directory traversal, somewhat similar to the execute bit on Unix. A directory with traversal disabled would disable all access, even if some sub directory would allow permission. A directory with traversal enabled but read disabled would allow only subdirectory access, for recursion. Unless the file has an overriding ACL, stating that the user can read. This is what I would call the default "noread" for files. A directory with read enabled and traversal disabled makes no sense, of course, like on Unix. :-) This change is somewhat more complicated, and maybe not feasible, but I wanted to note it, as a wishlist for the future.