Problem
<Filename> allows up to 256 characters under FEATURE_BUNDLE_1 (https://github.com/OpenJobDescription/openjd-specifications/blob/2c63e8a/wiki/2023-09-Template-Schemas.md#L1921-L1927).
An embedded file's filename is written verbatim as the on-disk basename by both sessions implementations, with no length check:
Common filesystems cap a single name component at 255: ext4/XFS/APFS at 255 bytes, NTFS at 255 UTF-16 units. A 256-character filename can therefore never be created.
Example
Template declares FEATURE_BUNDLE_1 with filename: "aaaa…" (256 × a). It decodes, create_job accepts it, the job is scheduled, and the worker fails with ENAMETOOLONG when writing the embedded file. A spec-valid template that no implementation can execute, and the failure surfaces at run time instead of at validation.
The spec also has no clause allowing an implementation to enforce stricter host-derived limits, so rejecting at 255 is non-conformant today.
RFC 0004 does not give a rationale for 256.
Proposal
Either:
- Change the
FEATURE_BUNDLE_1 maximum to 255; or
- Define the limit in bytes (255 bytes of the UTF-8 encoding), which also covers multi-byte names (see the related "characters" issue: 64 × 4-byte characters is already 256 bytes without the extension).
And optionally add a sentence allowing implementations to reject filenames that exceed the host's limits.
This is a one-number change before FEATURE_BUNDLE_1 is widely adopted; afterwards it is a breaking change.
Problem
<Filename>allows up to 256 characters underFEATURE_BUNDLE_1(https://github.com/OpenJobDescription/openjd-specifications/blob/2c63e8a/wiki/2023-09-Template-Schemas.md#L1921-L1927).An embedded file's
filenameis written verbatim as the on-disk basename by both sessions implementations, with no length check:Common filesystems cap a single name component at 255: ext4/XFS/APFS at 255 bytes, NTFS at 255 UTF-16 units. A 256-character filename can therefore never be created.
Example
Template declares
FEATURE_BUNDLE_1withfilename: "aaaa…"(256 ×a). It decodes,create_jobaccepts it, the job is scheduled, and the worker fails withENAMETOOLONGwhen writing the embedded file. A spec-valid template that no implementation can execute, and the failure surfaces at run time instead of at validation.The spec also has no clause allowing an implementation to enforce stricter host-derived limits, so rejecting at 255 is non-conformant today.
RFC 0004 does not give a rationale for 256.
Proposal
Either:
FEATURE_BUNDLE_1maximum to 255; orAnd optionally add a sentence allowing implementations to reject filenames that exceed the host's limits.
This is a one-number change before
FEATURE_BUNDLE_1is widely adopted; afterwards it is a breaking change.