Comment 1 for bug 926292

This was a hard one to track down but an easy one to fix. The make distcheck command was having difficulty with this:

find "distdir-1.0" -type d ! -perm -200 -exec chmod u+w {} ';' && rm -rf "distdir-1.0"

That find command fixes up directory permissions to make sure that they're writeable before trying to recursively delete the directory tree. I discovered that the chmod wasn't happening because when the find program stat'ed the directories, they showed up as writable. But then, strangely, the `rm -rf` failed with a permissions error.

After a lot of debugging to discover that the upper and lower inode's i_mode were getting out of sync somewhere, I then discovered that it was during a setxattr() call on the "system.posix_acl_access" extended attribute. If the lower filesystem modified the inode's i_mode because of a new POSIX ACL being created, eCryptfs was not mirroring those changes back up to the eCryptfs inode.

So, a subsequent stat on the eCryptfs inode could end up lying about the write permissions, causing find to never chmod the inode. But the lack of write permissions was, of course, enforced by the lower filesystem, resulting in the failed `rm -rf`.

Proposed fix posted here:

http://article.gmane.org/gmane.comp.file-systems.ecryptfs.general/139

Test case pushed here:

http://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/640

Since it is a trivial fix, I went ahead and pushed it to the eCryptfs -next branch and I plan on getting into Linus' tree soon.