Make the size field of ls correspond to to the size of the file

[Stebalien]

Currently, the size returned by ls is the size of the DAG under the link (using link.Size). However, most users will expect ipfs ls /some/directory to list the sizes of the files (as returned by ipfs cat /some/directory/file | wc -b).

Proposal:

1. Return a 0 (-1?) size for directories. Directory sizes really don't make sense.
2. Return the actual file size for files. That is, the size stored in the file's filesize field.

I highly doubt this will break any existing projects. Really, it's more likely to fix hidden bugs than it is to cause them.

See: ipfs/kubo#5906 (comment)

[magik6k]

Return a 0 (-1?)

I'd make it 0 as some things may expect uint

[achingbrain]

I’m massively in favour of this. Returning the DAG size is only useful to protocol spelunkers and is not verified by the codec so is not trustworthy.

For directories I’d prefer to omit the size field in the response instead of using 0 or -1.

[Stebalien]

@magik6k will omitting them be fine? We could also use the DAG size for directories (given that we can do whatever we want, really).

Historical note from @whyrusleeping: ipfs ls was originally supposed to be used for both files and merkledag objects (pre IPLD). ipfs file ls was supposed to be the command for listing files. However, that no longer really applies.

[magik6k]

I'd keep directory sizes in the response json, just not display them on the client

[kevina]

I'd keep directory sizes in the response json, just not display them on the client

Is there a reason foe this?

[Stebalien]

I'd keep directory sizes in the response json, just not display them on the client

Ideally, the user would be able to disable both --size and --resolve-type to avoid fetching the root block of every file in the directory.

[djdv]

Relevant: ipfs/kubo#5325

[Stebalien]

We've merged this change in go-ipfs.

[alanshaw]

@achingbrain do you have any bandwidth to pick this up and restore interop?