Switch git-lfs file size check from du -k to wc -c

[evbauer]

I'm having some trouble getting the lustre filesystem on my cluster to pass this check, which is erroneously returning a small number of 1K blocks despite the full file being in place. It looks like this wc -c check should work as an alternative. Would there be any downside to this?

[warrickball]

From a quick bit of searching online, if anything it seems that wc -c is better than du -h, at least for the purpose of this check. du reports how much space the disk is allocated to the file by the file system, whereas wc -c actually counts how many bytes are readable in a file.

The latter sounds more intensive but still seems very quick. The biggest file I could quickly find in a recent test checkout was eos/eosFreeEOS_data.tar.xz, for which wc -c returned the byte count in less than 15ms.

[VincentVanlaer]

I would do head -c4096 "${LFS_FILE}" | wc -c, that way we are not reading the entire file.

I am concerned about your file system though. Are you running the checkout and the build on the same node?

[evbauer]

Good idea to not read the entire file. Yes, the checkout and build were all running on the same node, interactively through the mesa_test gem, and also when I ran each step myself. I couldn't really figure out what's going on with my filesystem, so maybe I should ask the sysadmins, but apparently this was normal behavior.

[VincentVanlaer]

I am wondering whether du -A would work instead then (assuming that option exists on macos as well). But I am equally happy with just trying to read the first part of the file.