| Summary: | getmntent() returns invalid, not existent paths in mntent.mnt_dir | ||
|---|---|---|---|
| Product: | uClibc | Reporter: | A.Mazur <deweloper> |
| Component: | Standard Compliance | Assignee: | unassigned |
| Status: | NEW --- | ||
| Severity: | major | CC: | buildroot, joao.fs.cardoso, uclibc-cvs |
| Priority: | P5 | ||
| Version: | 0.9.30.3 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: | Fix | ||
Created attachment 2353 [details]
Fix
Any reason to not apply the fix also to the mnt_fsname field? I have done it and tested with nfs and cifs having spaces in the path, and it works on uClibc-0.9.30.3. addmntent, getmntent encoding parts are unfortunately missing. Also, according to the manpage you cite, glibc seems to only encode a few octal values, not all. Please submit a proper, tested patch. See uclibc.org/FAQ.html#contrib |
getmntent() fills mntent.mnt_dir with a value directly obtained from /proc/mounts file, without processing octal escapes. This results in returning non-existent path names for file systems which are mounted in paths that contain whitespace characters. And, for example, this causes the `df' applet from busybox to fail for such filesystems. getmntent(3) linux man page says: > Since fields in the mtab and fstab files are separated by whitespace, octal > escapes are used to represent the four characters space (\040), tab (\011), > newline (\012) and backslash (\134) in those files when they occur in one of > the four strings in a mntent structure. The routines addmntent() and getmntent() > will convert from string representation to escaped representation and back. So applications may just assume that mntent.mnt_dir contains a valid, existing path to the mount directory which may be used directly.