> On Aug 26, 2021, at 8:57 AM, Alan Bateman <alan.bate...@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.
