bug#69873: Acknowledgement (df(1) does not display all UFS mountpoints as valid on FreeBSD)

I have now reported this upstream since I consider this to be a bug in the FreeBSD Linux compat layer: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277804

bug#69873: Acknowledgement (df(1) does not display all UFS mountpoints as valid on FreeBSD)

I did some more investigation with stat(2). Running native on FreeBSD with Python os package 'st_dev': $ df -t ufs | cut -f 6 -w | sed 1d | xargs -I% python ~/stat.py % /: 108 /tmp: 110 /var: 111 /var/tmp: 112 /usr: 113 /usr/local: 161 /usr/ports: 142 /usr/obj: 141 /usr/local/pgsql: 140 /var

bug#69873: df(1) does not display all UFS mountpoints as valid on FreeBSD

Disclaimer: I am not 100% certain whether this is a bug in GNU coreutils or FreeBSD Linux emulation layer because the behavior is weird. So, please bear with me. Consider the following output on FreeBSD 13 from FreeBSD's df(1): $ df -t ufs -b -T -a Filesystem Type 512-blocks

bug#68256: df fails on /run/user/1000/doc with "Operation not permitted"

tag 68256 notabug close 68256 stop On 05/01/2024 09:22, Nada Machkova wrote: hello I have just upgraded Debian Bullseye and simple df command respond at user CLI $ df -hT df: /run/user/1000/doc: Operation not permitted ... but when I do the same as root there is NO error. So I UNmounted

bug#68256: df fails on /run/user/1000/doc with "Operation not permitted"

hello I have just upgraded Debian Bullseye and simple df command respond at user CLI $ df -hT df: /run/user/1000/doc: Operation not permitted ... but when I do the same as root there is NO error. So I UNmounted relevant file and AFTER that df response has NO error for user # fusermount -u /run

bug#66441: df: duplicated NFS4 bind mounts with the same device

I get duplicates on this reproducer with plain df, i.e. without -a. Originally, the issue was reported for RHEL 8 [1] but I can reproduce it even on the latest stable release of coreutils shipped with Fedora Rawhide. $ mkdir -p /original /bind1 /bind2 $ mount.nfs server:/nfs /original -v

bug#65331: tests/df/skip-rootfs.sh fails on WSL2

tests/df/skip-rootfs.sh + create_exe_shims_ /home/bill/Source/coreutils-9.3/./src + case $EXEEXT in + return 0 + shift + test 0 '!=' 0 + export PATH + print_ver_ df + require_built_ df + skip_=no + for i in "$@&qu

bug#58881: Question: df Size

On 2022-10-29 12:31, linux wrote: Can you write in man why df shows different result than lsblk ? Not easily, as that depends on the internals of the filesystem, which is out of coreutils's control and/or view. df is simply repeating what the kernel reports about the filesystem

bug#58881: Question: df Size

{ $ LC_ALL=C ./df -h  /dev/sda2 Filesystem  Size  Used Avail Use% Mounted on /dev/sda2   101G   21G   75G  22% / } { $ LC_ALL=C lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT /dev/sda2 NAME FSTYPE   SIZE MOUNTPOINT sda2 ext4    102.4G

bug#55748: df: wrong column is checked in condition in total-verify.sh

tag 55748 notabug close 55748 stop On 01/06/2022 09:01, Daniel Hofstetter wrote: Hi, While looking at https://github.com/coreutils/coreutils/blob/master/tests/df/total-verify.sh I noticed the following lines and I think "$5" in the last line (line 38 in the source code) should be &q

bug#55748: df: wrong column is checked in condition in total-verify.sh

Hi, While looking at https://github.com/coreutils/coreutils/blob/master/tests/df/total-verify.sh I noticed the following lines and I think "$5" in the last line (line 38 in the source code) should be "$6" because there are six columns in the df output and '-' is in the six

bug#54427: df command doesnt report correct output

On Mär 16 2022, Fariya F wrote: > Any idea what is the Overhead blocks and why the Overhead blocks is showing > a huge number? Looks like the filesystem superblock has been corrupted. You should probably copy the data to a new storage medium. -- Andreas Schwab, sch...@linux-m68k.org GPG Key

bug#54427: df command doesnt report correct output

Hi, My eMMC device has a partition which reports the below output from df -h command: Filesystem Size Used Avail Use% Mounted on /dev/mmcblk2p316Z 16Z 84M 100% /data the partition is of size 100MB though! The partition is ext4 formatted. As can be seen above, the output reports

bug#53052: Unusual df output

Dear coreutils devs, I'm the dev of the 'boot-repair' and 'boot-info' utilities. A Linux Mint 20.2 user reported the following system information:https://paste.ubuntu.com/p/kcXPDC79RF/ (pastebin will expire so I attach a copy) Interesting extract for you, is that line 20 shows unusual df

bug#53037: df/total-verify fail with cephfs

On 1/5/22 15:25, Dylan Simon wrote: Hrm, no, with this patch it still fails, but differently (sorry so many filesystems): OK, then perhaps someone with a bit more free time will have to look at it - unless you can propose a patch that passed "make check".

bug#53037: df/total-verify fail with cephfs

1 659883101% /run/user/1000 total 141179331 -934077896 1075257227 - - 2117679175 != 141179331 at check-df line 14, <> line 15. In case it's helpful, here's the statfs: statfs("/mnt/ceph", {f_type=FUSE_SUPER_MAGIC, f_bsize=4194304, f_blocks=724

bug#53037: df/total-verify fail with cephfs

On 1/5/22 14:11, Dylan Simon wrote: Then it will look like this (I'm inferring, haven't actually tried it): I'm still not quite following, but does the attached patch address the problem?diff --git a/src/df.c b/src/df.c index b803fc73b..8a0293ca9 100644 --- a/src/df.c +++ b/src/df.c @@ -127,6

bug#53037: df/total-verify fail with cephfs

>From Paul Eggert , Wed, Jan 05, 2022 at 01:05:03PM -0800: > On 1/5/22 11:27, Dylan Simon wrote: > > Only adding rows with all known values > > might make sense but would still break the test (wrong total total instead): > > > >if (known_value (iv->total) && known_value (iv->available)) { > >

bug#53037: df/total-verify fail with cephfs

On 1/5/22 11:27, Dylan Simon wrote: Only adding rows with all known values might make sense but would still break the test (wrong total total instead): if (known_value (iv->total) && known_value (iv->available)) { grand_fsu.fsu_files += iv->total; grand_fsu.fsu_ffree +=

bug#53037: df/total-verify fail with cephfs

We have a filesystem that reports statfs f_files = nfiles, f_ffree = -1 (UINTMAX_MAX). (See rationale https://github.com/ceph/ceph/pull/36127) Unfortunately this breaks df -i --total and in particular the df/total-verify test fails. Example output: > df -i --total / /mnt/ceph Filesys

bug#50940: how df utility displays sizes - GB vs GiB

On 10/4/21 13:31, Chris Murphy wrote: Is the primary target audience for human-readable values humans? Or scripts Both. Output columns are at a premium, so there is some advantage to omitting the units suffix (plus a lot of tradition for omission, outside of coreutils).

bug#50940: how df utility displays sizes - GB vs GiB

On Fri, Oct 1, 2021 at 12:19 PM Pádraig Brady wrote: > > On 01/10/2021 14:28, Danie de Jager wrote: > > Hi, > > > > The output from df -h and df -H is always G or M. Depending on who sends me > > usage stats I have to ask how the command was run to make sure I

bug#50940: how df utility displays sizes - GB vs GiB

the same options, but to trigger the longer annotation, we > > double the characters used to -hh and -HH? > > Interesting idea. Normally, later options override earlier, so 'df -h > -H' is equivalent to 'df -H'. This is so that one can alias 'df' to 'df > -h' and then type plain 'd

bug#50940: how df utility displays sizes - GB vs GiB

On 10/1/21 2:16 PM, Glenn Golden wrote: Might it be possible to finesse the already existing envars (BLOCK_SIZE, DF_BLOCK_SIZE, etc.) to accomplish the desired suffixing mods? We've been moving away from using those environment variables, for security and reproducibility reasons.

bug#50940: how df utility displays sizes - GB vs GiB

Paul Eggert [2021-10-01 14:01:14 -0700]: > > On 10/1/21 1:30 PM, Danie de Jager wrote: > > Can we use the same options, but to trigger the longer annotation, we > > double the characters used to -hh and -HH? > > Interesting idea. Normally, later options overri

bug#50940: how df utility displays sizes - GB vs GiB

On 10/1/21 1:30 PM, Danie de Jager wrote: Can we use the same options, but to trigger the longer annotation, we double the characters used to -hh and -HH? Interesting idea. Normally, later options override earlier, so 'df -h -H' is equivalent to 'df -H'. This is so that one can alias 'df

bug#50940: how df utility displays sizes - GB vs GiB

Thank you for sharing. After reading I agree that changing existing features could break processes for users. It would be easy to make mistakes when in a hurry and looking at the following output: $ df -h | grep /$ /dev/nvme0n1p1 12G 8.5G 3.6G 71% / $ df -H | grep /$ /dev/nvme0n1p1 13G

bug#50940: how df utility displays sizes - GB vs GiB

On 10/1/21 6:28 AM, Danie de Jager wrote: Systems like Amazon EC2 use the explicit GiB suffix. Are you saying that Amazon EC2's 'df' utility behaves differently from coreutils' 'df'? If so, could you send us documentation or source code indicating exactly what Amazon EC2's 'df' does

bug#50940: how df utility displays sizes - GB vs GiB

Danie de Jager [2021-10-01 15:28:10 +0200]: > > The output from df -h and df -H is always G or M. Depending on who sends me > usage stats I have to ask how the command was run to make sure I calculate > usage correctly. Systems like Amazon EC2 use the explicit GiB suffix. > M

bug#50940: how df utility displays sizes - GB vs GiB

On 01/10/2021 14:28, Danie de Jager wrote: Hi, The output from df -h and df -H is always G or M. Depending on who sends me usage stats I have to ask how the command was run to make sure I calculate usage correctly. Systems like Amazon EC2 use the explicit GiB suffix. Making it easier to know

bug#50940: how df utility displays sizes - GB vs GiB

Hi, The output from df -h and df -H is always G or M. Depending on who sends me usage stats I have to ask how the command was run to make sure I calculate usage correctly. Systems like Amazon EC2 use the explicit GiB suffix. Making it easier to know what sizes you are looking at. Can a future

bug#50432: DF shows incorrect disk usage which include disk usage of a mounted path

Paul, thanks for reply. Agree, it may be related with the file system. I use this workaround to add `--local` and `-x` flag for `df` to avoid the wrong calculation. I got the workaround from https://github.com/moby/moby/issues/42823#issuecomment-913584814. Best regards Paco 在 2021/9/8 下午

bug#50432: DF shows incorrect disk usage which include disk usage of a mounted path

On 9/8/21 12:02 AM, Paco Xu wrote: I use this workaround to add `--local` and `-x` flag for `df` to avoid the wrong calculation. I got the workaround fromhttps://github.com/moby/moby/issues/42823#issuecomment-913584814. Thanks for following up; closing the bug report.

bug#50432: DF shows incorrect disk usage which include disk usage of a mounted path

It sounds like df is reporting disk usage for the file system you're running your docker instance atop. In that case, there may be other uses of the file system, aside from the docker instance, which means df is reporting the correct numbers (and du is, too). The problem, if it is a problem

bug#50432: DF shows incorrect disk usage which include disk usage of a mounted path

On 06/09/2021 11:33 am, Paco Xu wrote: Hi, I am not quite familiar with the bug report process of `DF` or os. The Problem - DF shows incorrect disk usage which include disk usage of a mounted path The Scenario We run a registry with docker and the data dir is mounted from NFS

bug#50432: DF shows incorrect disk usage which include disk usage of a mounted path

Hi, I am not quite familiar with the bug report process of `DF` or os. The Problem - DF shows incorrect disk usage which include disk usage of a mounted path The Scenario We run a registry with docker and the data dir is mounted from NFS or local disk. The docker is using device-mapper

bug#50012: [PATCH] df: Fixed usage of incorrect stat data when using automount

Thank you for taking care. Your fix seems more elaborated and works for me. On 11.08.21 20:24, Paul Eggert wrote: On 8/11/21 8:59 AM, Thimo Emmerich wrote: Since the stat in [2]/df.c, line 1775 is necessary for the following fifo evaluation, it seems to be necessary to update the stat

bug#50012: [PATCH] df: Fixed usage of incorrect stat data when using automount

700 Subject: [PATCH] df: fix bug with automounted If the command-line argument is automounted, df would use stat info that became wrong after the following open. * NEWS: Mention the fix (bug#50012). * src/df.c (automount_stat_err): New function. This fixes the hang on fifos in a better way, by us

bug#50012: [PATCH] df: Fixed usage of incorrect stat data when using automount

This seems to be a regression from b04ce61958c1: "df: fix hang with fifo argument". When using df on an browsable automount map (in my case NFS mounts) df returns a screwed up information if the mount is not existing. During execution it triggers the mount via open() but it uses

bug#49298: [PATCH] df: do not print duplicated entires with NFS and bind mounts

On 30/06/2021 16:53, Kamil Dudka wrote: As originally reported in <https://bugzilla.redhat.com/1962515>, df invoked without -a printed duplicated entries for NFS mounts of bind mounts. This is a regression from commit v8.25-54-g1c17f61ef99, which introduced the use of a hash

bug#49298: [PATCH] df: do not print duplicated entires with NFS and bind mounts

On 2021/06/30 08:53, Kamil Dudka wrote: The proposed patch makes sure that the devlist entry seen the last time is used for comparison when eliminating duplicated mount entries. --- I'm a bit surprised that the devlists exported for NFS are the same as for smb. How is that guaranteed? But

bug#49298: [PATCH] df: do not print duplicated entires with NFS and bind mounts

As originally reported in <https://bugzilla.redhat.com/1962515>, df invoked without -a printed duplicated entries for NFS mounts of bind mounts. This is a regression from commit v8.25-54-g1c17f61ef99, which introduced the use of a hash table. The proposed patch makes sure that the devlist

bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000

On 2021/03/10 15:21, Paul Eggert wrote: Although his email did reencode those names into ISO 8859-1 which is more likely to cause problems than cure them these days, it still displays well on my MUA (Thunderbird) because its header said "Content-Type: text/plain; charset=iso-8859-1". His

bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000

On 3/10/21 2:50 PM, L A Walsh wrote: You are using a local 8-bit encoding, whereas everyone else was using UTF-8.  Your mailer re-encoded their messages into one of the 8-bit western encodings, whereas most people use UTF-8 these days, so while their original messages with accents came through

bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000

On 2021/03/10 14:09, Glenn Golden wrote: Second, minor, side rant: Would be nice if more attention was paid to fixing mailers encoding "Pádraig" and "Bénézech" as "P�draig" and "B�n�zech" If you see substitute encodings like that, it strongly suggests the problem is your MUA, not

bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000

> > > wrote: > > > > Dear maintener, > > > > > > > > I found a reproducible bug in df utility, installed in debian stable > > > > > > > > $ df --version |head -1 > > > > df (GNU coreutils) 8.30 > > > >

bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000

On 2021/03/10 06:50, Glenn Golden wrote: Pádraig, Philippe, Paul - Pádraig Brady [Tue, 9 Mar 2021 19:51:45 +]: On 09/03/2021 12:58, Philippe Bénézech via GNU coreutils Bug Reports wrote: Dear maintener, I found a reproducible bug in df utility, installed in debian stable $ df

bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000

Pádraig, Philippe, Paul - Pádraig Brady [Tue, 9 Mar 2021 19:51:45 +]: > > > On 09/03/2021 12:58, Philippe Bénézech via GNU coreutils Bug Reports wrote: > > Dear maintener, > > > > I found a reproducible bug in df utility, installed in debian stable > > &

bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000

On 3/9/21 4:58 AM, Philippe Bénézech via GNU coreutils Bug Reports wrote: df displays G instead of GM as unit size for Gigabytes in power of 1000 (but the value is correct) $ df -BGB /home Sys. de fichiers blocs de 1GB Utilisé Disponible Uti% Monté sur /dev/mapper/ssd2    421GB   355GB

bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000

unarchive 18119 forcemerge 18119 47023 stop On 09/03/2021 12:58, Philippe Bénézech via GNU coreutils Bug Reports wrote: Dear maintener, I found a reproducible bug in df utility, installed in debian stable $ df --version |head -1 df (GNU coreutils) 8.30 $ cat /etc/debian_version 10.8 df

bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000

Dear maintener, I found a reproducible bug in df utility, installed in debian stable $ df --version |head -1 df (GNU coreutils) 8.30 $ cat /etc/debian_version 10.8 df displays G instead of GM as unit size for Gigabytes in power of 1000 (but the value is correct) $ df -BGB /home Sys. de

bug#46749: Fedora 33 from USB - "df" bug

I have a system I just had to rebuild due to disk failure. :=[[[ I built a Fedora 33 release from the USB download and encountered a couple problems (one reported to redhat), but this one is with "df" and redhat does not cover that. Anyway, after I have been logged in a while DF emit

bug#37702: Suggestion for 'df' utility

On Fri, Jul 10, 2020 at 04:29:21PM -0700, Bryce Harrington wrote: > On Mon, Jun 01, 2020 at 09:26:14AM -0700, Bryce Harrington wrote: > > On Mon, Jun 01, 2020 at 09:04:26AM -0700, Bryce Harrington wrote: > > > On Sun, May 31, 2020 at 01:49:24PM +0100, Pádraig Brady wrote: > > > > On 31/05/2020

bug#37702: Suggestion for 'df' utility

posed through libmount, however gnulib explicitly does not want to depend on libmount. If there is a different way to access this info on a mount point that can be filtered on, it might be a helpful refinement. I don't know if there are many use cases for non-snap squashfs that would need displayed in

bug#37702: Suggestion for 'df' utility

Paul Eggert wrote: > So I'd prefer having 'df' just do the "right" thing by default, and > to have an option to override that. The "right" thing should be to > ignore all these pseudofilesystems that hardly anybody cares about. +1! Which I thought I would say because

bug#37702: Suggestion for 'df' utility

\ > > >|| strcmp (Fs_type, "subfs") == 0\ > > >/* for Linux 2.6/3.x */ \ > > This code appears to be part of gnulib, so I take it the patch would > need to be added there? Would it also need updates to any tests,

bug#37702: Suggestion for 'df' utility

moving away from environment variables > > > and/or > > > config files for the usual security and other-hassle reasons. So I'd > > > prefer > > > having 'df' just do the "right" thing by default, and to have an option to > > > override that. The &qu

bug#37702: Suggestion for 'df' utility

> >+ || strcmp (Fs_type, "tmpfs") == 0\ > > tmpfs is consumable, so wouldn't be appropriate to add I think +1 No space left on a tmpfs file system mounted e.g. on /tmp is a common problem that should be easily visible from the default output of df. Kamil

bug#37702: Suggestion for 'df' utility

Hi John, On Sun, May 31, 2020 at 06:52:04PM +1000, John Pye wrote: > The purpose of "df" is to show "disk free". Hence any filesystems that > are read-only or which are FUSE-mounted one on of the local physical > filesystems, or similar things (what others?) shou

bug#37702: Suggestion for 'df' utility

is not nice either. In other utilities we've been moving away from environment variables and/or config files for the usual security and other-hassle reasons. So I'd prefer having 'df' just do the "right" thing by default, and to have an option to override that. The "right" thing

bug#37702: Suggestion for 'df' utility

In other utilities we've been moving away from environment variables and/or > config files for the usual security and other-hassle reasons. So I'd prefer > having 'df' just do the "right" thing by default, and to have an option to > override that. The "right" thing sho

bug#37702: Suggestion for 'df' utility

Hi all My vote would be on a "df -a" switch to revert to original behaviour of visibility of all mounts. The purpose of "df" is to show "disk free". Hence any filesystems that are read-only or which are FUSE-mounted one on of the local physical filesystems,

bug#37702: Suggestion for 'df' utility

usual security and other-hassle reasons. So I'd prefer having 'df' just do the "right" thing by default, and to have an option to override that. The "right" thing should be to ignore all these pseudofilesystems that hardly anybody cares about.

bug#37702: Suggestion for 'df' utility

Hi all, On 30.05.20 05:18, Bryce Harrington wrote: On Fri, Oct 11, 2019 at 12:56:20PM -0700, Paul Eggert wrote: On 10/11/19 11:20 AM, Pádraig Brady wrote: if you want to exclude nested file systems like that, you could try:   alias df='df -x squashfs' On my Fedora 30 workstation

bug#37702: Suggestion for 'df' utility

On Fri, Oct 11, 2019 at 12:56:20PM -0700, Paul Eggert wrote: > On 10/11/19 11:20 AM, Pádraig Brady wrote: > > > > if you want to exclude nested file systems like that, > > you could try: > > > >   alias df='df -x squashfs' > > On my Fedora 30 workstation

bug#39273: unwanted behavior in the combination of an scenario regarding btrfs, ssh, borg, and 'df' from the core utils

his stuff is inside the kernel so df and coreutils are not the problem here. You might ask the Linux-BTRFS mailing list about this. It appears to be related to a known issue in their code; see: https://lore.kernel.org/linux-btrfs/f1f1a2ab-ed09-d841-6a93-a44a8fb23...@gmx.com/T/ On 2/4/20 6:56 AM, W

bug#39273: unwanted behavior in the combination of an scenario regarding btrfs, ssh, borg, and 'df' from the core utils

freespace by then, df, and KDE Plasma widgets show me 0 Byte left, but Rsync finished without error, and the borg repositorie is working troubleless remote. As soon as i run again into that error i will do the procedure you described me, and send in the requested datas. Thanks for the heads-up

bug#39273: unwanted behavior in the combination of an scenario regarding btrfs, ssh, borg, and 'df' from the core utils

On 1/24/20 11:50 AM, Wismerhill wrote: 'df' reports a wrong space calculation What's wrong about the space calculation? Please give the 'df' command that you ran, its faulty output, and also the output of 'strace' applied to the 'df' command that you ran. For example, on my machine, 'strace

bug#39273: unwanted behavior in the combination of an scenario regarding btrfs, ssh, borg, and 'df' from the core utils

Hi, My Name is Phil, i found an unwanted behavior in the combination of an scenario regarding btrfs, ssh, borg, and 'df' from the core utils. Scenario: I want to setup a home server (OpenSuse 15.1 - with newer kernel 5.4.13-9). I have 4 disks and want to use btrfs for a raid config (raid 5

bug#38573: coreutils 8.31 tests/df/skip-rootfs.sh fail when using rootfs

/pmem0 rw,nobarrier There's a lot of stuff there that probably is irrelevant for this issue. What is special about the build server is that it actually uses the original rootfs from its initrd. That is, it never mounts any other root fs and runs switch_root or chroot or anything. When I run df

bug#37702: Suggestion for 'df' utility

On 2019/10/11 12:56, Paul Eggert wrote: > On 10/11/19 11:20 AM, Pádraig Brady wrote: > >> if you want to exclude nested file systems like that, >> you could try: >>alias df='df -x squashfs' >> > On my Fedora 30 workstation that option doesn't make

bug#37702: Suggestion for 'df' utility

On 10/14/19 1:01 AM, Kamil Dudka wrote: This is not an excuse to introduce new problems. I'm not looking for an "excuse". df (through no fault of its own) has evolved into a bad program that needs fixing. Backward compatibility concerns are real and we should take them in

bug#37702: Suggestion for 'df' utility

er systems do expect to see. > > No matter what we do (even if we do nothing), there will be problems. This is not an excuse to introduce new problems. > But doing > nothing is clearly a bad idea, as the output of plain df is quite bad > right now in typical use. We can do better

bug#37702: Suggestion for 'df' utility

. But doing nothing is clearly a bad idea, as the output of plain df is quite bad right now in typical use. We can do better than that, even if we cannot be perfect and we cause problems by changing defaults. Out of curiosity, can you share the output of the following commands on the same system

bug#37702: Suggestion for 'df' utility

On 2019-10-14 00:13, Assaf Gordon wrote: > Also in other systems where "/tmp" is a "tmpfs", > users might want to see how much space is available. > > If we hide it by default, they can of course use "df /tmp" > or "df --all" - it's not abou

bug#37702: Suggestion for 'df' utility

Hello Bernhard, On 2019-10-13 3:57 p.m., Bernhard Voelker wrote: On 2019-10-13 23:28, Paul Eggert wrote: In any sane system there would be only four lines of non-header output (for tmpfs etc, /, /home, and /media/eggert/B827-D456), but df is outputting 28 lines. What is so special about

bug#37702: Suggestion for 'df' utility

On 2019-10-13 3:28 p.m., Paul Eggert wrote: [..] I mean c'mon, here's the output of 'df' on the Ubuntu 18.04.3 LTS workstation I'm typing this particular message on. In any sane system there would be only four lines of non-header output (for tmpfs etc, /, /home, and /media/eggert/B827-D456

bug#37702: Suggestion for 'df' utility

On 2019-10-13 23:28, Paul Eggert wrote: > In any sane system there would be only > four lines of non-header output (for tmpfs etc, /, /home, and > /media/eggert/B827-D456), but df is outputting 28 lines. What is so special about tmpfs so that you would like to see it? H

bug#37702: Suggestion for 'df' utility

ace it, df's utility for ordinary interactive use has degraded significantly with time due to all the random filesystems people have been adding, and we shouldn't keep our heads in the sands about this. df's default needs to change, one way or another. I mean c'mon, here's the output of 'df' o

bug#37702: Suggestion for 'df' utility

the problem for my workstation. This is roughly akin to the "used==0" test you're suggesting. I would humbly suggest caution with such unexpected user-facing changes to the default output of 'df' - learning the lessons from changing the quotes in 'ls'. Countless users have been

bug#37702: Suggestion for 'df' utility

to the "used==0" test you're suggesting. (I don't know if this would address the problem of small snap loop devices. I haven't seen sample df output from that.) What you mean by "available==0"? Actual zero-size filesystems, or filesystems whose size is less than some

bug#37702: Suggestion for 'df' utility

On 11/10/2019 20:56, Paul Eggert wrote: On 10/11/19 11:20 AM, Pádraig Brady wrote: if you want to exclude nested file systems like that, you could try:   alias df='df -x squashfs' On my Fedora 30 workstation that option doesn't make any difference. Regardless of whether '-x squashfs

bug#37702: Suggestion for 'df' utility

On 10/11/19 11:20 AM, Pádraig Brady wrote: if you want to exclude nested file systems like that, you could try:   alias df='df -x squashfs' On my Fedora 30 workstation that option doesn't make any difference. Regardless of whether '-x squashfs' is used, I see this output from 'df

bug#37702: Suggestion for 'df' utility

On 11/10/2019 08:55, John Pye wrote: Hi there I got this email address from the 'df' man page. Hope it's still active and the right place for feedback. With recent changes to Ubuntu and the increasing use of 'snap' packaging for all sorts of things, the 'df' utility output is now quite jumbled

bug#37702: Suggestion for 'df' utility

Hi there I got this email address from the 'df' man page. Hope it's still active and the right place for feedback. With recent changes to Ubuntu and the increasing use of 'snap' packaging for all sorts of things, the 'df' utility output is now quite jumbled and messy. My fairly normal system now

bug#35137: [df] incorrect parsing of /proc/self/mountinfo with \r in mount path

On 4/18/19 8:19 AM, Bernhard Voelker wrote: > [...] Meanwhile, I intend to just pull in the gnulib change with > a NEWS entry - patch attached. I had to include another later gnulib commit: https://git.sv.gnu.org/cgit/gnulib.git/commit/?id=22b911f63ca1 Pushed for coreutils at:

bug#35137: [df] incorrect parsing of /proc/self/mountinfo with \r in mount path

d, 8 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 6844228be..12c864dcc 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,13 @@ GNU coreutils NEWS-*- outline -*- ** Bug fixes + df now correctly parses the /proc/self/mountinfo file for unusual entries

bug#35137: [df] incorrect parsing of /proc/self/mountinfo with \r in mount path

Hi, I don't know this codebase, so can't comment on the patch, but the same bug in util-linux was solved by ditching scanf. https://github.com/karelzak/util-linux/commit/e902609400a861dbdb47d5c3eb98b951530bf01d

bug#35137: [df] incorrect parsing of /proc/self/mountinfo with \r in mount path

parsing /proc/self/mountinfo more robust * NEWS: Mention the fix. Fixes https://bugs.gnu.org/33468 --- NEWS | 7 +++ gnulib | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 6844228be..132f2a0f3 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,13 @@ GNU coreut

bug#35137: [df] incorrect parsing of /proc/self/mountinfo with \r in mount path

Bernhard Voelker wrote: +/* Find the next white space in STR, terminate the string there in place, + and return that position. Otherwise return NULL. */ + +static char * +terminate_at_blank (char const *str) +{ + char *s = NULL; + if ((s = strchr (str, ' ')) != NULL) +*s = '\0'; +

bug#35137: [df] incorrect parsing of /proc/self/mountinfo with \r in mount path

itional context. >> >> $ mkdir "$(echo -e foo\\rbar)" >> $ sudo mount -t tmpfs tmpfs foo^Mbar/ >> $ cat -v /proc/self/mountinfo|grep foo >> 865 39 0:59 / /tmp/foo^Mbar rw,relatime shared:462 - tmpfs tmpfs rw,seclabel >> $ df -h | grep foo >> $ df -

bug#35137: [df] incorrect parsing of /proc/self/mountinfo with \r in mount path

62 - tmpfs tmpfs rw,seclabel $ df -h | grep foo $ df -h /tmp/foo$'\r'bar Filesystem Size Used Avail Use% Mounted on - 3.9G 0 3.9G 0% /tmp/foo?bar When asked to show all filesystems, the mount point is not shown at all. When asked to show just that one, df parses the m

bug#32236: df header corrupted with LANG=zh_TW.UTF-8 on macOS

le system locale needs to match the current user's locale or otherwise df will not output all original characters. That has the potential to break scripts, as mismatched encodings is a common issue. In the attached I've taken the original less aggressive replacement policy when not outputting t

bug#33785: df: don't suppress remote mounts

tags 33785 notabug close 33785 stop Hello, On 2018-12-19 10:05 a.m., Pádraig Brady wrote: On 17/12/18 22:42, lzhong wrote: According to the following commit commit 2e81e62243409c5c574b899f52b08c000e4d99fd df: only suppress remote mounts of separate exports with --total

bug#33785: df: don't suppress remote mounts

On 17/12/18 22:42, lzhong wrote: > Hi list, > > According to the following commit > > commit 2e81e62243409c5c574b899f52b08c000e4d99fd > Author: Pádraig Brady > Date: Wed Oct 29 02:49:17 2014 + > > df: only suppress remote mounts of separate exports with

bug#33785: df: don't suppress remote mounts

Hi list, According to the following commit commit 2e81e62243409c5c574b899f52b08c000e4d99fd Author: Pádraig Brady Date:   Wed Oct 29 02:49:17 2014 +     df: only suppress remote mounts of separate exports with --total ... diff --git a/NEWS b/NEWS index 5d3bc58bd..2c7e590e0 100644

bug#6816: df bug on 64-bit Solaris (need to use getextmntent)

Hello Assaf, > > 2018-10-12 Bruno Haible > > > > mountlist: Improve support for Solaris in 64-bit mode. > > Reported by David Wood in > > . > > * m4/ls-mntd-fs.m4 (gl_LIST_MOUNTED_FILE_SYSTEMS): On Solaris 8 or > >

bug#7972: Bug df: GunWin32 coreutils-5.3.0 Windows 7 32bit and windows 2008 64bit

tags 7972 notabug close 7972 stop (triaging old bugs) On 2011-02-03 7:48 a.m., Eric Blake wrote: On 02/02/2011 10:49 PM, Trevor Kohlman wrote: df: cannot read table of mounted file systems: Invalid argument. Thanks for the report. However, you should raise this as a bug with the GnuWin32

bug#6816: df bug on 64-bit Solaris (need to use getextmntent)

Hello Bruno, On 2018-10-12 10:17 a.m., Bruno Haible wrote: David Wood wrote: At this point, me->me_dev contains a wrongly packed (32-bit) device number, which forces the find_mount_point() code path (causing other unpleasantries). The following patch against coreutils v8.5 fixes the problem:

bug#22517: dd byte count report does not correlate with df byte count report

tags 22517 notabug close 22517 stop (triaging old bugs) On Tue, Feb 02, 2016 at 12:20:36AM +0100, Bernhard Voelker wrote: > On 02/01/2016 05:53 AM, Bob Gustafson wrote: > > > > Expected results: > > > > I would think that the sizes reported by dd

  1   2   3   4   5   6   7   8   >