denoland
bug: `fs.copy()` throws permission error because it requires CWD access
Here's a repository containing an example to replicate the bug: https://github.com/ChiKler/-Deno-error-Uncaught-PermissionDenied-read-access-to-CWD-
I believe that's because you use copySync() from std, which (without a good reason) calls path.resolve() which requires CWD access. It shouldn't call path.resolve().
Originally posted by @nayeemrmn in https://github.com/denoland/deno/pull/2875#issuecomment-723579312
@ayntee , can you clarify what you are pointing to? Do you mean we cannot use allow list for read permission because copySync() uses Deno.lstatSync()? Deno.lstatSync is only called on src so it should work by giving src and dest in the allow list.
@ChiKler, path.resolve() is called to normalize the paths. Say input is foo.txt to copySync, that should be normalized to /home/.../foo.txt (thanks to @lucacasonato for the insight). I'm trying to find out a possible solution because the normalized paths might be required for the function to work as expected
Edit: The solution is here is to not allow path.resolve to use Deno.cwd() at all. This will be a breaking change. After this change, path.resolve will need the first parameter to be Deno.cwd() in case of relative paths as parameter. I've started working on it but the pr might take time given many dependents :)
As Yoshiya said in #3875, a valid reason to keep the use of path.resolve() is that it checks for path equality (if the source and destination files are the same). I think a solution to this would be to have Deno.copyFile() throw an error when both paths are the same and then handle the thrown error. I.e. solve https://github.com/denoland/deno/issues/19464. @bartlomieju, WDYT?
