summaryrefslogtreecommitdiffstats
path: root/bin/df
diff options
context:
space:
mode:
authorcsjp <csjp@FreeBSD.org>2004-07-20 18:24:47 +0000
committercsjp <csjp@FreeBSD.org>2004-07-20 18:24:47 +0000
commitdb0285e2e3356f87b8f3215bfafbea3dab26e1d0 (patch)
tree420e461d75773b4d8c0bce6d9802d6f07acc18b0 /bin/df
parent8c938ed70a0b0d695f2d2c2577503b1b3b9365ec (diff)
downloadFreeBSD-src-db0285e2e3356f87b8f3215bfafbea3dab26e1d0.zip
FreeBSD-src-db0285e2e3356f87b8f3215bfafbea3dab26e1d0.tar.gz
Currently if a mount point is not accessible by the calling user,
invalid information will be printed if the -t flag is specified. $ df -t ufs Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 495726 139944 316124 31% / /dev/ad0s1e 253678 6438 226946 3% /tmp /dev/ad0s1f 56206340 13594248 38115586 26% /usr /dev/ad0s1d 694126 19812 618784 3% /var /dev/ad0s1d 694126 19812 618784 3% /var $ Note that the mount point which is not accessible shows up as the previous file system that was printed. The reason for this is that df -t will call statfs(2) on the pathname supplied by getfsstat(2). This is done to refresh the file system statistics in the event that a previous file system had a long delay in providing its stats. This change affects the df utility in the following ways: o Teach df has to deal with statfs(2) failing. If statfs(2) fails, fall back on the possibly stale stats provided by the initial call to getfsstat(2). o Print a warning that the fs stats could possibly be stale o Modify the man page and document this new behavior as a bug. Approved by: bmilekic (mentor) PR: 68165
Diffstat (limited to 'bin/df')
-rw-r--r--bin/df/df.14
-rw-r--r--bin/df/df.c20
2 files changed, 18 insertions, 6 deletions
diff --git a/bin/df/df.1 b/bin/df/df.1
index 76d3a02..8deaefc 100644
--- a/bin/df/df.1
+++ b/bin/df/df.1
@@ -149,7 +149,9 @@ is set, the block counts will be displayed in units of that size block.
.Sh BUGS
The
.Fl n
-flag is ignored if a file or file system is specified.
+flag is ignored if a file or file system is specified. Also, if a mount
+point is not accessible by the user, it is possible that the file system
+information could be stale.
.Sh SEE ALSO
.Xr lsvfs 1 ,
.Xr quota 1 ,
diff --git a/bin/df/df.c b/bin/df/df.c
index ddeb581..dfff6ae 100644
--- a/bin/df/df.c
+++ b/bin/df/df.c
@@ -298,7 +298,7 @@ getmntpt(const char *name)
static size_t
regetmntinfo(struct statfs **mntbufp, long mntsize, const char **vfslist)
{
- int i, j;
+ int error, i, j;
struct statfs *mntbuf;
if (vfslist == NULL)
@@ -308,10 +308,20 @@ regetmntinfo(struct statfs **mntbufp, long mntsize, const char **vfslist)
for (j = 0, i = 0; i < mntsize; i++) {
if (checkvfsname(mntbuf[i].f_fstypename, vfslist))
continue;
- if (!nflag)
- (void)statfs(mntbuf[i].f_mntonname,&mntbuf[j]);
- else if (i != j)
- mntbuf[j] = mntbuf[i];
+ /*
+ * XXX statfs(2) can fail for various reasons. It may be
+ * possible that the user does not have access to the
+ * pathname, if this happens, we will fall back on
+ * "stale" filesystem statistics.
+ */
+ error = statfs(mntbuf[i].f_mntonname, &mntbuf[j]);
+ if (nflag || error < 0)
+ if (i != j) {
+ if (error < 0)
+ warnx("%s stats possibly stale",
+ mntbuf[i].f_mntonname);
+ mntbuf[j] = mntbuf[i];
+ }
j++;
}
return (j);
OpenPOWER on IntegriCloud