> > Thanks for the suggestion. > > From a user perspective, I can see the attraction of this functionality > (and generally of --verbose), but from an implementation perspective, > even --verbose is not welcome because it adds a nontrivial amount of > logic (and the threat of a large performance hit) for only marginal gain. > The worst part is that must of what ch??? --verbose prints is not even > guaranteed to be true, so it cannot be used reliably to infer prior state. > While working on ch???.c over the years, --verbose support has turned > out be the source of enough hassles that I have seriously considered > deprecating-then-removing the option. Thus, the relatively-new > chcon.c (which is very similar to the other ch*.c programs) does *not* > provide a --verbose option. > > Here's a big part of the problem: > > - what chown/chgrp/chmod --verbose reports with your proposed > addition may not be true. There is a guaranteed race: the > original owner/group/mode may be changed between when the > tool records it and when it comes time to actually change it. > It could end up not being changed at all, or it could be changed > from some other value than the one printed in the diagnostic. > > With that, you get a feel for why I'm tempted to remove --verbose > support. Even existing --verbose output may be inaccurate due to > this implicit race condition. For example, if I run chgrp --verbose G f, > it may print "changed group of `f' to G", while in actuality it may not > have changed the group at all, due to the unavoidable race when using > --verbose. > > If you really want the prior state, you should simply record it > separately, rather than hoping to get something consistent and > usable from --verbose. > > In summary I'd rather remove --verbose from ch??? >
I definitely see your point. While I didn't notice that there was a race condition, I definitely did see, in chown-core.c anyway, a fair amount of the logic was devoted toward actually printing the correct (or, as you have pointed out, possibly incorrect, depending on the outcome of the race condition) information. Deprecating seems like the way to go if there aren't too many scripts that will break because of it. (I don't know how often it is used, I really don't use ch??? much because I am the only user of my computers.) Are there any other small-median features, such as this one that someone would like done that you could see a practical reason for implementing? -- "Once GNU is written, everyone will be able to obtain good system software free, just like air."-- RMS in the GNU Manifesto
