cmd: fix files ls to report hash and size for files

[schomatis]

Fixes #5044.

[schomatis]

I'll add some tests (or probably some already existing tests should be fixed).

[schomatis]

The test is failing because the reported size varies for reasons I don't quite understand, I'll raise a different issue for that and leave this as blocked in the meanwhile.

[Stebalien]

I wonder if we need fo flush first or something...

[schomatis]

Now that you mention it, maybe we need to lock the directory, that's what ForEachEntry does when it gets the node (that's where I copied the patch from),

https://github.com/ipfs/go-ipfs/blob/1e9e2f453c435272433a96ebfba5c4319cc08534/mfs/dir.go#L262-L274

(but that may just be due to the childUnsync call, I can't tell).

[Stebalien]

Sorry, I missed that commit before my comment. It looks like you fixed the size issue, right? The code looks corect, at least.

[Stebalien]

LGTM modulo the magic number.

[Stebalien]

Should probably use unixfs.TFile to avoid magic numbers.

[schomatis]

Yes, I should directly call the Type() function, 1 isn't even the actual value of TFile.., thanks!

[achingbrain]

@Stebalien looks like @schomatis addressed your PR comments, can this be merged?

[kevina]

I'm not sure but I think this might change the output of ipfs ls <file> when -l is not used. Please add a test for that.

[kevina]

Please add a test for the ls output without -l is unchanged when used on a file.

[Stebalien]

Nice catch!

[schomatis]

I'm not sure but I think this might change the output of ipfs ls when -l is not used.

@kevina The field of the NodeListing structure displayed when -l isn't used is just Name,

https://github.com/ipfs/go-ipfs/blob/7e8f6c96047e1a94c1c892aa50e1c75e01b7fda2/core/commands/files.go#L485-L492

which was already set in the (unmodified) gopath.Split() line.

That being clarified, always happy to add more tests :)

[kevina]

@kevina The field of the NodeListing structure displayed when -l isn't used is just Name,

Okay the reason I bring it up is that 'ls /afile' should not fail if the hash for /afile is not available. But a quick test on the exiting version of IPFS verified this is not the case, so this is not a regression but something that could be cleaned up later.

so LGTM.

[schomatis]

'ls /afile' should not fail if the hash for /afile is not available.

Good point, I should be replicating the logic of the *mfs.Directory case where that information is loaded only if long is true (-l option), let me fix that and get back to you.

[schomatis]

Fixed, @kevina could you take another look please?

Just to clarify, in the file case, the node has already been fetched through MFS, so getting its hash (or any other information) won't fail, in contrast, in the directory case, after the directory node is fetched other nodes need to be looked in the DAG (files inside the directory) for the command to build its output, leaving open the door for an potential error.

However, even if this case can't fail, it should do the amount of work it needs to do and not more, so it needs to also (as the directory case) discriminate the -l true/false cases.

[schomatis]

Oh, fun fact, I've just realized that the Type field that was hard-coded isn't even needed, I'm still leaving it in the PR just in case future version do show it (it's cheap to compute).