size reported for "type=dir" headers is 0 about go-mtree HOT 9 CLOSED

Clarification: Size() reports the size of the contents of a particular file, in which when called on a directory header, it is expected that there is nothing in that directory, hence size 0. Instead, what we actually want is the size of the directory structure itself.

from go-mtree.

i'm not seeing that. Interesting.
Here is a comparison of upstream mtree and go-mtree

vbatts@bananaboat ~ (master) $ mtree -c -p ./bin | grep type=dir
.               type=dir mode=0775 nlink=3 size=4096 \
.sync           type=dir mode=0775 nlink=2 size=4096 \
vbatts@bananaboat ~ (master) $ gomtree -c -p ./bin | grep -w dir
. size=4096 type=dir mode=0775 nlink=3 time=1467130505.015551996
.sync size=4096 type=dir mode=0775 nlink=2 time=1386609429.618041696

from go-mtree.

Sorry for the confusion; I haven't run the actual go-mtree command, this is output from printing information about the tar headers within readHeaders() in tar.go.

from go-mtree.

oh. well yes. the tar stream. It will be zero in the tar header. But on disk it will be 4096 bytes. that is a notable translation.

from go-mtree.

right, but can we just assume that folders on disk will always be 4096 bytes?

from go-mtree.

very typically the size of the link to the inode, is 4kb. Though, it may be
safer to just not include the size= for directories.

On Tue, Jul 5, 2016 at 11:28 AM, Stephen Chung [email protected]
wrote:

right, but can we just assume that folders on disk will always be 4096
bytes?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#12 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAEF6aUdSPqAuohPGKARr31bVQZSJ3N9ks5qSngqgaJpZM4JClEZ
.

from go-mtree.

hmm, won't that be an issue when we try to create the actual mtree spec and subsequently when we try to validate a file hiearchy with this spec?

from go-mtree.

if the size= keyword is not present in a /set nor for a specific entry,
then it is not validated.

On Tue, Jul 5, 2016 at 1:03 PM, Stephen Chung [email protected]
wrote:

hmm, won't that be an issue when we try to create the actual mtree spec
and subsequently when we try to validate a file hiearchy with this spec?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#12 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAEF6eiRipZZzKGP8uO9_jcmAEayYAB9ks5qSo58gaJpZM4JClEZ
.

from go-mtree.

okay sounds like we should leave this keyword out for now. thanks for clarifying.

from go-mtree.