automake distdir.test fails because of an EPERM error
Bug #926292 reported by
Tyler Hicks
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
eCryptfs |
Fix Released
|
Medium
|
Tyler Hicks | ||
linux (Ubuntu) |
Fix Released
|
Medium
|
Tyler Hicks | ||
Lucid |
Fix Released
|
Medium
|
Colin Ian King | ||
Natty |
Fix Released
|
Medium
|
Colin Ian King | ||
Oneiric |
Fix Released
|
Medium
|
Colin Ian King | ||
Precise |
Fix Released
|
Medium
|
Tyler Hicks |
Bug Description
Reported by Sebastien Bacher:
Run this:
$ apt-get source automake1.11 && cd automake1.11-1.11.1 && ./configure && make && cd tests && ./distdir.test
It will fail like so:
cp: cannot remove `distdir-
make[1]: *** [distdir] Error 1
It works on ext4. I've reproduced it in Precise (3.2.0.12.12) and upstream (3.3-rc2) kernels.
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → Medium |
assignee: | nobody → Tyler Hicks (tyhicks) |
Changed in linux (Ubuntu Precise): | |
milestone: | none → ubuntu-12.04-beta-1 |
tags: | added: rls-p-tracking |
Changed in ecryptfs: | |
status: | Confirmed → In Progress |
Changed in linux (Ubuntu Precise): | |
milestone: | ubuntu-12.04-beta-1 → ubuntu-12.04-beta-2 |
tags: | added: precise |
Changed in linux (Ubuntu Oneiric): | |
importance: | Undecided → Medium |
assignee: | nobody → Colin King (colin-king) |
status: | New → In Progress |
Changed in linux (Ubuntu Lucid): | |
status: | New → Confirmed |
Changed in linux (Ubuntu Natty): | |
status: | New → Confirmed |
Changed in linux (Ubuntu Lucid): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Natty): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Lucid): | |
status: | Confirmed → Fix Committed |
Changed in linux (Ubuntu Natty): | |
status: | Confirmed → Fix Committed |
Changed in linux (Ubuntu Oneiric): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Natty): | |
assignee: | nobody → Colin King (colin-king) |
Changed in linux (Ubuntu Lucid): | |
assignee: | nobody → Colin King (colin-king) |
Changed in linux (Ubuntu Lucid): | |
status: | Fix Committed → Fix Released |
Changed in linux (Ubuntu Natty): | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
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.