A difficulty is if a control were shown then people rightly expect it to work. However, deeper down the problem is not just access to the access control settings, it is the NCP access setting(s) themselves may invisibly vanish due to ordinary operations on a file (a copy on write step is an example). We need to remove the vanishing part of things.

Thus one solution is to retreat to allowing specific user NCP access permissions to be set only on directories, knowing that some sites will have to shuffle files about to retain the specific user access priv's on just selected files (i.e., create subdirectories for the special cases). Such a step would also mean changing what the NCP Client shows folks about such selected access controls. There might be better solutions.

The question is whether such an option should be a default or not.  Certainly not as an absolute only one way.

I can see shops that would have most systems set to off, with a few key people being allowed to do so where needed.  Perhaps part of this could be an eDirectory level right to be able to set such things.

What you describe is definitely an issue that I have encountered myself. If it were not possible to assign access rights to a file, they would have to be inherited from the directory but that can be done today.

I, for one, would not like to lose the ability to assign access rights to a file.

Just a little amplification for our understanding.

Imagine that one or several files have NCP rights assigned allowing several users to access them. Then a modification of one such file occurs and the NCP access rights do not follow a possible copy on write step of that application. The result is what those users thought they had access to is now one file less, which can be a surprize, with consequences. "Oh dear, sorry about that, are you alright, I will call a network.ambulance..."

When thinking about this I found the term "dependability" to describe the overall experience. People expect it, and rightly so. Thus there is a technical problem to be solved. Each of us can imagine some interesting quicky solutions, but the product team(s) needs to carry through the careful thinking and changes so that customers can do their work with reasonable confidence (dependability, no sudden loss of access etc, no user special training course).

Joe,

Yes this is an issue but it goes further than just COW file systems. I'm thinking of Microsoft Office documents which use COW when changes are made to a file.

When a new file is created it inherits the access permissions assigned to (or inherited by) the directory in which they reside. If the access permissions are properly set at the directory, COW will not impact the files. 

If it were not possible to assign access permissions to a file I can see where that may impact certain customers. For example, If a directory contained a large number of PDF files it may be desirable to limit access to some of them to specific users. If access permissions couldn't be assigned to individual files they would have to be segregated to specific directories based on who may be permitted to access them. I see this becoming a real can of worms. :-)