On 26/08/2021 15:43, Alan Snyder wrote:
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?
You are welcome to propose additional tests if you want.
I also think it would be good to have a specific exception to use for such
cases.
It would to have optional (see the "Optional Specific Exceptions"
sections of the javadoc) as you can't guarantee that
ENAMETOOLONG/equivalent would happen in all 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?
I don't think this is feasible or a compatible change.
-Alan
