bin/74500 : [PATCH] allow chflags to set flags on symlinks

[Chris Dillon]

The following reply was made to PR bin/74500; it has been noted by GNATS.

From: Chris Dillon <cdillon at wolves.k12.mo.us>
To: bug-followup at FreeBSD.org, dnelson at allantgroup.com
Cc:  
Subject: Re: bin/74500 : [PATCH] allow chflags to set flags on symlinks
Date: Wed, 27 Jul 2005 15:27:35 -0500 (CDT)

 I wanted to point out that I have been using this patch for quite a 
 while now, but thought I would mention that the following part of the 
 patch is not strictly necessary:
 
   	if (Rflag) {
   		fts_options = FTS_PHYSICAL;
 +		if (hflag && (Hflag || Lflag))
 +			errx(1, "the -R%c and -h options may not be "
 +				"specified together", Hflag ? 'H' : 'L');
 
 
 It is OK to use '-R' and '-h', and '-H || -L' together, but may not 
 have the expected behaviour.  This behaviour is already (indirectly) 
 documented in the manual page, so there is no reason to prevent it.
 
 If the filespec to chflags contains a symlink, as expected, you must 
 use '-L' or '-H' to have that symlink in the filespec followed.  When 
 combining one of these options with '-h' and '-R', for example when 
 using '-h -H -R' with the filespec containing a symlink pointing to a 
 directory, the symlink and everything under the directory it is 
 pointing to will have its flag changed, but the actual directory the 
 symlink is pointing to (the link target) will NOT have its flag 
 changed.  This is the expected behaviour of the lchflags() system call 
 and is correct with that in mind.  Even the chflags(1) manual page 
 says '-h' will "change the flag of the link rather than the file to 
 which it points", so this is documented.
 
 With that in mind, I think we should also have an option to "change 
 the flag of the link AND the file to which it points".  This should 
 apply to chmod(1) and chown(1) as well.
 
 -- 
   Chris Dillon - cdillon(at)wolves.k12.mo.us
   FreeBSD: The fastest, most open, and most stable OS on the planet
   - Available for IA32, IA64, AMD64, PC98, Alpha, and UltraSPARC architectures
   - PowerPC, ARM, MIPS, and S/390 under development
   - http://www.freebsd.org
 
 Q: Because it reverses the logical flow of conversation.
 A: Why is putting a reply at the top of the message frowned upon?