copySync(src, dst, {preserveTimestamps: true}) fails with EACCES when copying a directory contains read-only file on Linux

[teknocat]

• Operating System: Xubuntu 16.04 LTS
• Node.js version: v8.12.0
• fs-extra version: 7.0.0

Copying a directory using the recursive copySync function with preserveTimestamps option fails with permission error on Linux if the target is a directory contains read-only file.
(This issue is similar to #599, but the problem still remains ever now)

Repro steps:

1. Create the following hierarchy:

root
|- file1 (r--r--r--)
|- file2 (rw-rw-r--)

2. Run the following node snippet:

const fse = require('fs-extra')
fse.copySync('root', 'target', {preserveTimestamps: true})

• Expected: success (like cp -pr root target)
• Actual: the target directory is created and file1 file, but not file2 and the following is printed:

fs.js:646
  return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
                 ^

Error: EACCES: permission denied, open 'target/file1'
    at Object.fs.openSync (fs.js:646:18)
    at utimesMillisSync (***/node_modules/fs-extra/lib/util/utimes.js:68:17)
    at copyFile (***/node_modules/fs-extra/lib/copy-sync/copy-sync.js:69:14)
    at onFile (***/node_modules/fs-extra/lib/copy-sync/copy-sync.js:51:37)
    at getStats (***/node_modules/fs-extra/lib/copy-sync/copy-sync.js:46:44)
    at startCopy (***/node_modules/fs-extra/lib/copy-sync/copy-sync.js:36:10)
    at copyDirItem (***/node_modules/fs-extra/lib/copy-sync/copy-sync.js:118:10)
    at fs.readdirSync.forEach.item (***/node_modules/fs-extra/lib/copy-sync/copy-sync.js:111:39)
    at Array.forEach (<anonymous>)
    at copyDir (***/node_modules/fs-extra/lib/copy-sync/copy-sync.js:111:23)

[mbargiel]

This actually happens on MacOS as well. A slightly simpler repro case:

1. Create the following file

file1 (r--r--r--)

2. Run the following node snippet:

const fse = require('fs-extra')
fse.copySync('file1', 'file2', {preserveTimestamps: true})

[mbargiel]

This seems to be a problem with the ordering of chmod and futimes, although I think the copy might itself set the mode. I'm looking into creating a PR for this.

[manidlou]

@RyanZim @mbargiel is this fixed by #633?

[mbargiel]

@RyanZim @mbargiel is this fixed by #633?

I don't know. As reported by the OP, this issue is similar to #599 which was presumably fixed by #600. However, this might be fixed indirectly by the logic I added in #633 such as explicitly making the target file writable before setting the timestamps. This could have been the problem.

Unfortunately I don't have a Linux box readily available but I can quickly test whether master currently works on MacOS with the specified repro steps.

[mbargiel]

@manidlou I confirm that on MacOS I get an error with 8.1.0 when using {preserveTimestamps:true} as in the OP's repro steps, with a nearly-identical stack trace. I also confirm that it does not happen on master, so #633 probably fixed, yes.

[manidlou]

Cool thanks @mbargiel! I leave it open until we release 9.0.0.

[RyanZim]

I'm gonna close this out as fixed by #633; I dislike having open issues that already have PRs merged for them. We can reopen if it isn't fixed.