3 ms·

> the actual argument value the JVM receives is "/jars/*", and in turn decides to be helpful, and expand the wildcard anyway Whenever I see such things, I imme

> the actual argument value the JVM receives is "/jars/*", and in turn decides to be helpful, and expand the wildcard anyway Whenever I see such things, I immediately think "whatever the resulting order is, it had better not matter"; and if it does, which is definitely true for Java classpaths, I consider it a bug that needs to be fixed ASAP, before it causes what happened in the article.

ivanjermakov 2y ago
Also, command line strings are limited to 128kiB on Linux: https://unix.stackexchange.com/questions/120642/what-defines-the-maximum-size-for-a-command-single-argument https://unix.stackexchange.com/questions/120642/what-defines...
kevincox 2y ago
Yeah, my jaw was dropping as I realized how far they went with this from checking their mount options to reading ext4 source code. Directly order is almost always an implementation detail (I'm pretty sure it is on ext4) and even if it isn't you still shouldn't rely on it (for when someone decides to migrate your production machines to BTRFS because they want snapshots and now your app has some weird breakage). The problem is that the app depends on directory order, and you need to fix that, not figure out how you can predict the directoy order. Maybe there should be a mount options to randomize directory order that people can use in their staging environments.
- MrDrMcCoy 2y ago
  > Maybe there should be a mount options to randomize directory order that people can use in their staging environments. The behavior I've witnessed suggests that the the order is based on inode numbering, which is initially sequential from creation time, and drifts semi-randomly as inodes are unlinked and reused. I don't know this for a fact, but it makes enough sense. Directory ordering should be assumed to be random in all cases, as you suggest.

3 ms·

> the actual argument value the JVM receives is "/jars/*", and in turn decides to be helpful, and expand the wildcard anyway Whenever I see such things, I imme

by userbinator 2y ago

ivanjermakov 2y ago
Also, command line strings are limited to 128kiB on Linux: https://unix.stackexchange.com/questions/120642/what-defines-the-maximum-size-for-a-command-single-argument https://unix.stackexchange.com/questions/120642/what-defines...
kevincox 2y ago
Yeah, my jaw was dropping as I realized how far they went with this from checking their mount options to reading ext4 source code. Directly order is almost always an implementation detail (I'm pretty sure it is on ext4) and even if it isn't you still shouldn't rely on it (for when someone decides to migrate your production machines to BTRFS because they want snapshots and now your app has some weird breakage). The problem is that the app depends on directory order, and you need to fix that, not figure out how you can predict the directoy order. Maybe there should be a mount options to randomize directory order that people can use in their staging environments.
- MrDrMcCoy 2y ago
  > Maybe there should be a mount options to randomize directory order that people can use in their staging environments. The behavior I've witnessed suggests that the the order is based on inode numbering, which is initially sequential from creation time, and drifts semi-randomly as inodes are unlinked and reused. I don't know this for a fact, but it makes enough sense. Directory ordering should be assumed to be random in all cases, as you suggest.