On Fri, Oct 17, 2008 at 04:58:16PM -0700, Junio C Hamano wrote: > With 8ed0a74 (t1301-shared-repo.sh: don't let a default ACL interfere with > the test, 2008-10-16) applied is this still needed, or can I drop it from > my review box? Apologies for a tardy response, was out of town and away from keyboard for a day. This patch is still needed, as my and Matt's patch are solving two different issues with t1301. As he pointed out in the thread regarding his patch, the issue was that the testcase was intended to specifically test Git's interaction with permissions set via the umask, but a default ACL on the 'trash directory' could interfere with this, since they'd override the umask settings. Remove the ACL, no problem. My patch, on the other hand, is to deal with 'ls' output in case a file has certain filesystem extended attributes. These could be e.g. POSIX ACLs, or a SELinux security context, or perhaps others. If such an extended attribute is present, 'ls -l' will print permissions with a '+' appended, e.g. -rw-r--r--+ Instead of -rw-r--r-- However, t1301 reads permissions output by ls for several tests, and compares them to string representations such as that above. Without removing the '+', if present, the strings will not match. Furthermore, since this occurs for other filesystem extended attributes, and not just ACLs, it is not possible to simply strip all extended attributes from the file in question (with SELinux, the kernel won't let you remove a file's security context anyway). For what it's worth, I've experienced this failure on my Ubuntu 8.04 laptop with SELinux permissive mode, so it's possible ls behaves slightly differently on other systems; I've not been able to determine this one way or another. However, I see no harm in accounting for this situation in the general case, since the typical output of ls on other systems will not be affected nor modified with this patch. Hope that helps, Deskin Miller -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
