I think what constitutes a „too long path“ is highly environment and data dependent. For some OS it depends on configuration, version, filesystem type, mount structure, encoding, canonicalisation and API used. Java would have a really hard time to codify this all. So the current solution „try the native API and report errors“ sounds like the only really useable option - not to mention it is also safe (you get an error no crash). There are some unfortunate problems like OS where the gui limits more like the OS (Explorer) or where one path type (UNC or DOS-Short or relative) can create longer path than later readable, but basically for them it’s also hard for Java to predict and forbid them (especially if used intentionally).
What could be done is to document this, document which functions actually use OS APIs and possibly and which Path And Filesystem API does or does not. And hopefully the IOException and native error Handling can be Unified and improved (for example Expose Errno/HERR return codes in IOException attribute which avoids to parse (localized error messages). It’s a bit annoying but even if you want to handle it better: there is not much you can do if you have such a Path constructed. Limit inputs and install dirs and not use user provided names if your systems should be reliable. -- https://Bernd.eckenfels.net ________________________________ From: core-libs-dev <core-libs-dev-r...@openjdk.java.net> on behalf of Alan Snyder <javali...@cbfiddle.com> Sent: Thursday, August 26, 2021 12:12:33 AM To: core-libs-dev <core-libs-dev@openjdk.java.net> Subject: Re: what does the spec say about file paths that are too long? Lacking any new data, I guess it is fair to assume that there is no specification for the behavior of methods that use file paths that are too long, and presumably no tests, either. So the next question is whether there should be such a specification. I think there should be a specification because I would like to be able to use file paths without having to defend against possible unwanted bad effects when the paths are too long. By analogy, more like array indexing than integer overflow. If there is to be a specification, should it be at the method level? That would be best, I think. For example, the Path.toAbsolutePath() method in principle could return a path that is “too long” even if the original path is fine. Should an exception be raised at that point or only when the absolute path is used? This distinction was not possible with File, but it may be possible with Path, given the association with file providers. (Regarding the comment from Alan B., is it the case that file paths are necessarily resolved before use? That would surprise me.) Also, there is the possibility of creating a more specific exception to be thrown when paths that are too long are used. A case can be made for distinguishing this error from general IOExceptions because it is repeatable and explainable, unlike the general IOException. Thoughts? Alan > On Aug 20, 2021, at 7:05 AM, Alan Snyder <javali...@cbfiddle.com> wrote: > > Where did I say that I was seeing silent truncation? > > My question is about the specification. > > I want to know if I should write code that defends against silent truncation. > I should be writing code based on the specification, not what I observe in a > test program on a particular platform. > > I’m pleased that you believe an exception should be thrown, but is that > behavior mandated in the specification and tested by the JCK? > > Alan > > >> On Aug 20, 2021, at 2:58 AM, Alan Bateman <alan.bate...@oracle.com> wrote: >> >> Where are you seeing "silent truncation"? You should see an I/O exception if >> you attempt to access a file and the resolved file path is too long. >> >> -Alan >> >
