Trash spec: directory size cache

[David Faure]

Hi Mikhail!

Glad to hear from you.

On Friday 19 April 2013 22:48:05 Mikhail Ramendik wrote:
> I see an ambiguity in the text, as currently written. The ambiguity applies
> in cases a multilevel directory is trashed. Let us say that the directory
> foo was trashed; it contains the subdirectory bar.
> 
> In $trash/directorysizes there will be an entry for foo. But what about an
> entry for foo/bar? The problem is that "trashing a directory" is not
> exactly defined. I guess there will only be an entry for foo; can you
> confirm that?

Correct, this is only about direct children of $trash/files/.
This is actually clarified by the sentence

<P>The character '/' is not allowed in the directory name (even as %2F), since 
all these directories must be direct children of the "files" directory, and 
absolute paths are not allowed.</P>

> Also, the term "directory size" is used but not defined. Is "the sum of
> sizes of all files in the directory, including files in any subdirectories"
> a correct definition?

The way to calculate sizes is defined further down:

<P>The size is calculated to be the disk space used by the directory and its
contents, i.e. the size of the blocks, in bytes (like `du -B1` would 
calculate).</P>

> After you confirm, and if you don't mind, I'll make a revised release
> candidate. I'd like to fix a couple of old glitches as well (like a "note
> the dot" endnote where the dot no longer exists". I'll make sure to have a
> diff against the released version too.

Sure, please do. Maybe do that as an additional commit on top of mine, and in 
the end one of us pushes both commits together? This way it'll be easier to 
review your changes (without diff'ing diffs).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5