mirror of
https://github.com/pnpm/pnpm.git
synced 2026-03-26 11:02:01 -04:00
055dc8ff4e
* fix(importer): handle ENOTSUP error in linkOrCopy during parallel imports On Linux CI, copy_file_range/sendfile can transiently fail with ENOTSUP under heavy parallel I/O on the same CAS store files. Fall back to manual read+write when copyFileSync hits this error. * fix(importer): preserve file mode in ENOTSUP fallback and add tests Address review feedback: - Preserve source file permissions (mode) when falling back to read+write on ENOTSUP - Add tests for the ENOTSUP fallback path and for rethrow of non-ENOTSUP errors * fix(importer): handle ENOTSUP in all copyFileSync paths The previous fix only handled ENOTSUP in linkOrCopy, but the error can occur in any code path that calls copyFileSync: the copy import method, atomicCopyFileSync, and the clone function. Extract resilientCopyFileSync that falls back to read+write when copy_file_range/sendfile fails with ENOTSUP, and use it in all paths: - linkOrCopy (hardlink fallback) - copyPkg (copy import method) - atomicCopyFileSync (package.json completion marker) - createCloneFunction (tolerate ENOTSUP alongside EEXIST) * fix(importer): don't swallow ENOTSUP in clone function ENOTSUP from COPYFILE_FICLONE_FORCE means "reflinks not supported" and must propagate so the auto importer falls through to hardlink. Only the regular copyFileSync path (resilientCopyFileSync) should handle ENOTSUP as a transient copy_file_range failure. The previous commit incorrectly tolerated ENOTSUP in the clone function, causing it to silently skip files and produce empty directories.