what does the spec say about file paths that are too long?

[Alan Snyder]

> On Aug 26, 2021, at 8:57 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 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.
> 


Thanks. However, I think the specification issue should be addressed first.

One writes test programs to find cases where the code does not obey the specification. It’s hard to do that if the specification does not address the behavior of interest.



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

It seems this case is already covered, at least in part. From the spec for FileSystem.getPath:

    An implementation may choose to reject path strings that contain names that are longer than those allowed by any file store.

All that is missing is the case where the entire path exceeds some hard limit.