RFR: 8073061: (fs) Files.copy(foo, bar, REPLACE_EXISTING) deletes bar even if foo is not readable [v2]

[Alan Bateman]

On Thu, 31 Aug 2023 21:09:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 919:
>> 
>>> 917:             } else if (!sourceAttrs.isSymbolicLink() || flags.followLinks) {
>>> 918:                 // Ensure source can be read
>>> 919:                 provider.checkAccess(source, AccessMode.READ);
>> 
>> I don't think this will work with a SM set as that will trigger a check that the SM will allow read before it checks if there is read access at the file system level (move is specified to check the SM for write access to both source and target).
>
> I modified it in f09b468031ad542ba11e491a8091ea96a12d311d only to verify that the source has write access at the file system level.
> 
> I think that checkRead(), however, should be called if the move is effected as a copy + delete instead of as a rename. In this case,  move() calls copyFile() which does not check with the SM that there is permission to read the source. In copy(), checkRead() is called before copyFile() is invoked.

The spec for Files.move is that the SM is called to checkWrite on both source and target. I would need to dig into ancient history to page in the reasons why it's not checkDelete on the source and checkWrite on the target.  In any case, for the change here, it can't introduce a checkRead without doing a spec change. So checking it to use provider.checkAccess is right as that will just check file access.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1312603803