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 >> >
