pathconf() does not reflect reality
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
eCryptfs |
Fix Released
|
High
|
Tyler Hicks | ||
linux (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Lucid |
Fix Released
|
Undecided
|
Unassigned | ||
Maverick |
Won't Fix
|
Undecided
|
Unassigned | ||
Natty |
Fix Released
|
Undecided
|
Unassigned | ||
Oneiric |
Fix Released
|
Undecided
|
Unassigned | ||
Precise |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
In the face of letting a program discover what the maximum length of a filename is on an eCryptfs mount point, the pathconf() routine appears to lie:
kees@sec-
/home/kees/.Private on /home/kees/Private type ecryptfs (ecryptfs_
kees@sec-
255
kees@sec-
touch: cannot touch `AAAAAAAAAAAAAA
failed: 144
Changed in ecryptfs: | |
status: | New → Triaged |
importance: | Undecided → High |
assignee: | nobody → Tyler Hicks (tyhicks) |
Changed in ecryptfs: | |
status: | Triaged → In Progress |
Changed in linux (Ubuntu Lucid): | |
status: | New → Fix Committed |
Changed in linux (Ubuntu Oneiric): | |
status: | New → Fix Committed |
Changed in linux (Ubuntu Natty): | |
status: | New → Fix Committed |
Changed in linux (Ubuntu Maverick): | |
status: | New → Won't Fix |
Changed in ecryptfs: | |
status: | In Progress → Fix Released |
Thanks again, Kees. Note to myself:
statfs(".", {f_type= "EXT2_SUPER_ MAGIC", f_bsize=4096, f_blocks=18226758, f_bfree=5764244, f_bavail=4838356, f_files=4636672, f_ffree=3988217, f_fsid= {-1849260021, -1854857501}, f_namelen=255, f_frsize=4096}) = 0
ecryptfs_statfs() does several wrong things, f_namelen being one of those.