S3 ListObjectsV2 endpoint returns malformed XML when filenames contain invalid UTF-8 sequences

Affected Product: OneFS 9.7, 9.13, and earlier

S3 `ListObjectsV2` API requests fail with XML parsing errors on the client side. This issue occurs selectively when the requested bucket contains files with names that include invalid character encodings or non-UTF-8 byte sequences. 

If a client attempts to access one of these specific offending files directly by S3, OneFS will correctly throw a `400(InvalidURI): Path cannot be encoded as UTF-8 string` error. However, during a `ListObjectsV2` directory walk, the API request succeeds with an HTTP 200 OK, but delivers a malformed XML payload that fails the client's parser.

The S3 protocol requires that object keys (filenames) are represented as valid ASCII or UTF-8 strings. 

During a `ListObjectsV2` request, OneFS uses a translation function (`enc_utf8ify`) to convert filenames into UTF-8. If a filename contains garbage bytes (such as an invalid sequence delivered by an older NFSv3 client), the conversion fails. When this happens, the S3 daemon's fallback logic blindly injects the raw, unconverted filename bytes directly into the XML response payload. Because standard XML parsers mandate valid character encoding, the presence of these raw, non-UTF-8 bytes breaks the XML tree for the entire bucket listing.

To permanently fix this issue, a code patch (Tracked in PSCLDF-9443) must be applied to the S3 daemon so it gracefully handles translation failures without failing the XML payload. 

OneFS has a framework designed to ensure the integrity of names from protocols that use a "bag-of-bytes" model (like NFSv3). When the file system encounters an invalid UTF-8 sequence, its standard behavior is to map the illegal bytes into the Unicode Private Use Area (PUA)—specifically within the `U+ED00 - U+EDFF` range. By mapping these illegal bytes into this PUA range, OneFS can safely encode the string without breaking parsers. 

Any case of this issue seen should be escalated to Engineering (referencing internal tracking for the `ns_object.c` fallback flaw) to align the S3 `ListObjectsV2` endpoint with this native `U+ED00 - U+EDFF` PUA substitution logic, or to alternatively substitute the invalid bytes with the standard Unicode replacement character (`U+FFFD`).

Workaround
Because the S3 API cannot reliably list or process these objects, you must track down the offending files using an alternate protocol (SMB, NFS, or local CLI access) and rename them to conform to valid ASCII or UTF-8 formatting.