Skip to content

node.js idea of an inode is approximately broken

The Tweet points to the bug report.

After the facepalming there is still a lot to say about that.

About the bug: There is a system call stat(2) in Posix, which returns a struct stat as a result. Part of that data structure is a field st_ino, which contains the inode number of that file. That number is a unique file identifier, a 64 bit bit pattern.

Javascript does not have integer types to represent that number, so node.js has been falsely converting it to a float, which can hold 53 bits of precision. So on certain file systems, 2048 different files will be munged together, which is extremely bad.

Possible solutions are obvious: Use a string or use two 32-bit numbers to hold full precision values.

About Javascript: Javascript is a language used in browsers, and changing the specs of Javascript is incredibly hard. Basically, you have to get everybody to update their browsers in order to actually make progress.

There are things that do crypto with Javascript as a target language, and there are compilers from proper programming languages to portable Javascript as a target. But still, Javascript itself is poisonous, and while that take on the language is humorous, this is a serious problem.

About culture: So we are getting a generation of developers now, which have been growing up without hardware or state. They learned programming on AWS and take RDS for granted, which means they have never actually seen hard(-ware related) problems.

They also learned programming with the Javascript framework of the week, and think that real software can be written this way. The result is not only the mess that s npm, but also an attempt at systems programming resulting in constructs such as this.

I cannot for the life of me stand the coddly approach to teaching of Julia Evans (check out her writeups at her blog), but apparently what she does and how she does it is necessary and appropriate for people growing up in a programming environment like this. Well, I’m ok with that if it prevents mindsets and bugs like the one above.

Published inComputer ScienceErklärbär


  1. Rudolf Polzer

    Given about the only thing you ever do with inode numbers in application code is compare them equal or nonequal, a string seems the obvious solution.

    However it is very easy to accidentally convert it to a number, losing precision again, in JavaScript.

    So I wonder if another encoding would be better – e.g. a hex string, or even base64. At least accidental conversions to Number will be noticed rather quickly there.

  2. Johannes

    It could also prefix the inode to prevent the conversion, while still making it trivial to compare the value to the one from another system. (While I’m not seeing many use cases for that)

    The proper solution would be to have some “large” integer support, but this probably would require v8 to change and I guess that would require ECMAScript’s standard body to derive from the stance that double was the only numeric type needed …

  3. Hans Java

    You should mention that this is an Windows-Only problem and Inodes are not really common under this OS.

    Aber hauptsache gegen JS, wie alle alten?

    • Johannes

      Auf meinem Linux ist ino_t ein 64bit-Wert. Nichts hindert ein Filesystem höhere Werte zu benutzen und es ist ein flaw in der Sprache, dass es nur einen numerischen Typ, Numeric aka. IEEE 754 double precision float, gibt der 52 bit + sign flag hat, mit denen man nen präzisen Wert abbilden kann (52 Bit Mantisse, 11 bit Exponent, 1 Bit sign = 64 bit) und der bei Werten, für die 52 bit nicht reichen ungenau wird, ohne dass man das kontrollieren kann.

      • Rudolf Polzer

        Aber man kann es doch kontrollieren.

        Wie in jeder anderen Sprache gibt es built-in-Typen mit begrenzter Genauigkeiten (bei JS eben nur einen), und man kann mit entsprechenden Libraries beliebig große/genaue Zahlen verwenden.

        JS-typisch ist nur, dass viele Entwickler die Grenzen des eingebauten Number-Typs offenbar nicht kennnen.

    • Rudolf Polzer

      On Windows, according to MSDN:

      Time of creation of file. Valid on NTFS but not on FAT formatted disk drives.
      Drive number of the disk containing the file (same as st_rdev).
      Number of the information node (the inode) for the file (UNIX-specific). On UNIX file systems, the inode describes the file date and time stamps, permissions, and content. When files are hard-linked to one another, they share the same inode. The inode, and therefore st_ino, has no meaning in the FAT, HPFS, or NTFS file systems.

      This is already barely compatible to unix semantics (all three quoted fields have quite different semantics from Unix), so it’s unlikely node.js makes it any worse.

      • kris kris

        The observed behavior is not specific to Windows NT. It just so happened that Windows has been the first system to trigger it. Other systems have a 64 bit st_ino field as well, but most peoples file systems are not large enough (do not have enough files) to exceed the counter and other file systems happen to use up inodes linearly (an implementation artifact).

  4. Inodes sind alternative Facts.

  5. AndreasLobinger

    Manchmal, aber nur manchmal denke ich mir: Wenn wir es schaffen Fahrzeuge autonom zu machen, damit man den Leuten die nicht selber fahren sollten das Steuer aus der Hand nehmen zu können, dann sollten wir uns danach auf autonome SW Entwicklung fokussieren um damit Leuten die Tastatur aus der Hand zu nehmen, die nicht selber programmieren sollten.

    • Mich hat heute nachmittag eine Oma die Beifahrerin war in einem silbernen Passat wild gestikulierend verflucht weil ich in Ulm auf der B10 in einer 50er Zone 50 gefahren bin.

      Der Opa der da noch dazu gehoert hat ist gefahren und zeigte sichtlich amuesiert auf die 50er Schilder um sie zu beruhigen und ihr zu versichern dass hier alles nach rechten Dingen vorgeht.

      In Neu-Ulm sind sie dann abgefahren. Schade, wollte wissen ob daraus ein waschechter Scheidungskrieg wird. Mit 90 ist sowas sicher spannend.

  6. Olaf Klischat

    Inodes aren’t related to hardware, they’re related to file systems, which you get to tinker with on AWS just as well if you want…

    As to JavaScript — let’s just say it’s better than PHP. :-P

Leave a Reply

Your email address will not be published. Required fields are marked *