As I said, I think it's great that we agree an exception should be thrown when an over-length path is used in an actual file operation.
However, would it not be better to have that in the specification, rather than relying on the opinions of individual engineers expressed in a thread on a mailing list? And would it not also be better if there were test cases? I also think it would be good to have a specific exception to use for such cases. Regarding path resolving, I am not surprised that the JDK may have to resolve paths before use in some cases. Your original comment seemed to imply that *all* uses were resolved by the JDK first, and that would surprise me. Granted that path operations cannot in general predict when a path will be of usable length in a file operation, the question remains whether path operations should report over-length paths in those cases where it can be determined. Is it not the case that some OS APIs have hard limits on path length (unrelated to limits imposed by the file system itself)? For a file provider using such an API, would throwing an exception when that limit is exceeded be a good idea or a bad idea? Alan > On Aug 26, 2021, at 3:39 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 25/08/2021 23:12, Alan Snyder wrote: >> 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.) > As I said, you should see an I/O exception if you attempt to access the file > system with a file path that is too long to locate a file. There are a couple > of APIs that return a boolean rather than throw and they should all fail > (usually by returning false) if the file path is too long. If you do find a > case where you think the file path is "silently truncated" then please bring > it up so we can see if this is a JDK or operating system issue. There was > some exploration, in the JDK 7 time frame, into defining APIs that expose > limits but it gets unapproachable very quickly due to handling by specific > operating systems and encoding/normalization at the low-level file system > level. > > I see your other mails asking if resolving or combining paths should fail. > That is not feasible in general. Bernd mentioned some of the issues. If you > add sym or hard links to the discussion then you will quickly see that you > don't actually know which file system or file will be accessed until you > attempt the access. You also mentioned being surprised that the JDK may have > to "resolve" paths. It has to in some cases, the most obvious being long > paths on Windows that need transformation and a prefix to order to generate > the file path for the Windows call. > > -Alan. >
