On Mon, Oct 27, 2014 at 11:54:57AM +0000, Pádraig Brady wrote:
On 10/27/2014 08:36 AM, Harald Dunkel wrote:
On 10/24/14 18:24, Pádraig Brady wrote:
Note /home doesn't seem to be accessible above
which is another reason to prefer /data here.
What do you mean by "not accessible"? Both /home and
/data work fine.
I was referring to the fact that "-" was shown for the /home entry:
nfs-home:/space/home - - - - /home
nfs-home:/space/data 13390666752 10768854016 1941581824 85% /data
That's df's doing. Potentially something like this would get the
suggested behavior:
--- src/df.c.orig 2014-10-27 12:14:39.633167418 -0400
+++ src/df.c 2014-10-27 13:16:54.524752800 -0400
@@ -631,6 +631,10 @@
/* Stat failed - add ME to be able to complain about it
later. */
buf.st_dev = me->me_dev;
}
+ else if (me->me_remote)
+ {
+ /* ignore duplicate network mounts */
+ }
else
{
/* If we've already seen this device... */
@@ -928,7 +932,7 @@
if (stat (stat_file, &sb) == 0)
{
char const * devname = devname_for_dev (sb.st_dev);
- if (devname && ! STREQ (devname, disk))
+ if (devname && ! STREQ (devname, disk) && !me_remote)
{
fstype = "-";
fsu.fsu_blocksize = fsu.fsu_blocks = fsu.fsu_bfree =
The question then being whether making this case work breaks other
cases, and whether making it that much harder to explain the logic of
what df displays is worth it to avoid explaining why a particular set of
mounts is captured by the current logic. :)
Mike Stone
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
