GNU bug report logs - #35488
Feature du --files-only request

Previous Next

To reply to this bug, email your comments to 35488 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Ellenberger <davidmarioellenberger <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Feature du --files-only request
Date: Mon, 29 Apr 2019 13:36:31 +0200

[Message part 1 (text/plain, inline)]

Dear maintainers

As you're probably aware, du --apparent-size calculates/reports 1 file
system block for a [empty] folder (typically 4096 bytes). I find that a bit
inconsistent with what the option suggests. The manual entry to
--apparent-size doesn't help the understanding.

From a practical point of view, when we admins copy a folder&files
structure from one to another file system where block size doesn't
correspond, we cannot use du to get a count comparison and have to resort
to something like:
$ ls -anR | grep -v '^d' | awk '{total += $5} END {print total, "Bytes"}'

Windows explorer shows zero bytes for an empty folder or folder containing
multiple empty folders. This way, comparing two copied folders&files's
content by size works out well regardless of file system and its block
sizes it uses.

I understand that admins have become accustomed to see 4096 in directories
as it's consistent with the ls command and the technicality behind it.

In my daily admin tasks I never had to count sizes of empty folders. The
overhead of provisioning and enable the file system to work is something we
typically accept and do not require to re-calculate nor even to understand
in all details. Anyway, the FS provisioning and logical blocks perspective
is a complete different things for which we have the df command and other
tools.

I'd therefore suggest a new option --files-only (which calculates only the
size of files and skips over anything else that has a directory attribute
flag, device, symbolic link etc..).

Like that we would finally be able to count file sizes consistently align
with the du manual entry which says 'DESCRIPTION: Summarize disk usage of
each FILE, recursively for directories.'

Thanks for reading,

David

[Message part 2 (text/html, inline)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: David Ellenberger <davidmarioellenberger <at> gmail.com>
Cc: Coreutils <bug-coreutils <at> gnu.org>
Subject: Re: bug#35488: Feature du --files-only request
Date: Thu, 02 May 2019 02:39:55 -0700

On 4/29/2019 4:36 AM, David Ellenberger wrote:
> Dear maintainers
>
> I understand that admins have become accustomed to see 4096 in directories
> as it's consistent with the ls command and the technicality behind it.
>   
---
    Except that it isn't 4096 on all file systems.  For empty
directories, I usually see 0 bytes allocated.  And for very large
directories, it may be megabytes of space in the directory.
The directory takes real space on linux/unix and different depending
on what filesystem you use.  On windows in NTFS, directories, I think
can be virtual since the meta info and names are in a file control
block.  In that single case, the directories may really take zero
space in the file system, but that's a quirk of how NTFS works in
windows.  If the real intent is to measure used disk space, including
directories seems advisable as they can take real space on most
file systems that is counted against a user quota if it exists.

    Confusingly, depending on the file-allocation block size on the
source and target (they are often 4k, but don't have to be) and on
the amount of ***fragmentation*** in the free space, of the source
and target.  If free space is heavily fragmented, a directory may
need to be spread out into several areas, making it larger than
necessary if free space wasn't so fragmented.  That's why you often
hear people say you should keep about 15-25% of your disk space
free -- thats so large contiguous areas won't entirely disappear and
storage will be more efficient.

    Anyway, just my opinion, but not sure if du should exclude
directories entirely, but I wouldn't be against separate subtotal
lines for directories and files -- that would make it even more helpful!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.