Am 16.10.10 01:27, schrieb Paul Eggert: > On 10/15/10 16:11, Thomas Keller wrote: >> And suddenly the test file lost its ACL - do'h! > > The file didn't lose its ACL. What happens is that a copy was > created, and then renamed over the original. At one point chmod is > applied to the copy, so that it has the right permissions. That's > what removes the default ACL.
Actually chmod(1) should not remove the ACL (and not even the default ACL, because this only exists on the directory), but maybe the problem is that the default directory ACL is not (automatically) applied to the newly created copy? See, I thought something like this and it made me look at how ACLs are actually implemented in Linux. It seems as if each application has to take care of ACLs with special syscalls itself and that it this is not automatically handled by the underlying file system, which is kind of a pity, because I guess many, many applications beside the core tools like cp and friends will probably ignore them by default. > This does appear to be a bug. One possible fix would be for 'patch' > to not do the chmod unless it really needs to, which typically it > doesn't. Or if a copy is created, simply copying over the ACLs of the old file to the new file before it is renamed. At least there is an option to do that in setfacl(1), this might be UI sugar, though. > This bug report really belongs in bug-patch, by the way, so I'll CC: > this followup here. The original thread is at > <http://lists.gnu.org/archive/html/bug-diffutils/2010-10/msg00015.html>. Ok, many thanks for the forward! Thomas. -- GPG-Key 0x160D1092 | [email protected] | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
