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.
