fs.stat returns a size of 0 for /proc/* files

[mleblebici]

Version

v16.15.1

Platform

Linux ubuntu 5.13.0-48-generic #54~20.04.1-Ubuntu

Subsystem

fs

What steps will reproduce the bug?

You can see the result by simply running the following code.

var fs = require('fs')
 
fs.stat('/proc/meminfo', (error, stats) => {
   console.log(stats)
})

How often does it reproduce? Is there a required condition?

There is no required condition, it always returns the same result.

What is the expected behavior?

It was expected to return actual file size.

What do you see instead?

Instead of actual file size, it shows size as 0.

Additional information

This is valid for files under /proc directory. fs.stat returns size as 0 for /proc/meminfo, /proc/cpuinfo, /proc/version and other files.
Below code from nodejs-procfs with a small modification, is able to return actual file size.

const getSize = path => {
	const fd = openSync(path, 'r', 0o666);
	let pos = 0;
	let bytesRead;
	let buf = tmpBuf;
	let length = buf.length;
	do {
		bytesRead = readSync(fd, buf, pos, buf.length - pos, null);
		pos += bytesRead;
		if (pos === tmpBuf.length) {
			length = length << 1;
			let newBuf = Buffer.allocUnsafeSlow(length);

			if (length <= tmpBufMaxLen) {
				tmpBuf = newBuf;
			}

			buf.copy(newBuf);
			buf = newBuf;
		}
	} while (bytesRead !== 0);
	closeSync(fd);
	return buf.toString('utf8', 0, pos).length;
};

[mscdex]

Returning zero agrees with the file size reported by the stat command on Linux, so I don't think there is any bug here.

[bnoordhuis]

That's indeed how /proc files work. Closing as not a bug.

[dougwilson]

Hi @mscdex @bnoordhuis thank you very much for your response! Any idea on how to tell the difference between a file like this and a file with an actual zero size? Should the docs at https://nodejs.org/dist/latest-v16.x/docs/api/fs.html#statssize be updated to note that it may return zero though the file actually does have contents? Perhaps including the same note in the Node.js docs that libuv does in http://docs.libuv.org/en/v1.x/fs.html

Note Any fields in the resulting uv_statfs_t that are not supported by the underlying operating system are set to zero.

[mscdex]

@dougwilson If node exposed an fs API that called uv_fs_statfs(), then you could check the resulting f_type specifically for procfs (that wouldn't give you a "real" size but would let you handle the file differently). Alternatively you could just check if the path to the file starts with '/proc'.

Otherwise you could just try opening the file and start reading it. Obviously in this case if you're sending this as an HTTP request/response you'd need to stream it instead of setting a Content-Length.

[dougwilson]

Thanks. What about updating the Node.js docs? Does the suggestion I put above make sense? I assume that Node.js has that libuv behavior, but just wanted to confirm before opening a pr to copy that note into the Node.js docs.

[mscdex]

AFAIK it's not an OS issue, but a filesystem issue. I wouldn't be surprised if the same situation could happen with other filesystem types in various scenarios.

[bnoordhuis]

I don't mind documenting it. It can double as a warning that stat-then-read is a pretty broken approach to slurping files because the file can change between stat and read.

(Not that I'm pointing any fingers. Node had the same bug at one point.)

[dougwilson]

Right, for sure. I'm thinking the following note would suffice:

Note: a value of 0 means that the file has a size of 0 or the underlying file system does not support returning the file size.