Repository navigation
split: retry short writes in custom_write so the input tail is not silently dropped - #15874
mavrodikomsd-eng wants to merge 1 commit into
Conversation
…lently dropped A single write() may accept only part of the data when the output volume fills up or a file size limit is reached. ByteChunkWriter then broke out of its loop on the short count and LineChunkWriter ignored the count entirely, so the last chunk could end up truncated with exit code 0. GNU split reports the write error instead. custom_write now keeps writing until all bytes are accepted; the next write() call surfaces the underlying error. BrokenPipe handling for --filter is unchanged. Fixes uutils#15820
Merging this PR will degrade performance by 12.65%2 warnings
Warning Please fix the performance issues or acknowledge them on CodSpeed. Performance Changes
Tip Investigate this regression by commenting Comparing Footnotes
|
Fixes #15820
custom_write()used a singleWrite::write()call, so a short write (e.g. the output volume filling up mid-write or a file size limit being hit) silently dropped the rest of the buffer:ByteChunkWriterbroke out of its loop on the short count andLineChunkWriterignored the count entirely. In the worst case the last chunk ofsplit -b/split -lcame out truncated with exit code 0, while GNU split reports the write error.The write loop now keeps going until all bytes are accepted; the next
write()call surfaces the underlying error, so a full volume orulimit -flimit results in a proper error exit like GNU. The--filterBrokenPipe handling is preserved: it still counts as a full write.Testing: added unit tests around the new
write_repeating()helper with mock writers covering short writes, a filling device,BrokenPipe(ignored and not ignored) and zero-progress writes. The 4 pre-existingtest_split_number_*failures on Windows are unchanged (they also fail on current main without this patch).