[9] RFC on 8073061: Files.copy(foo, bar, REPLACE_EXISTING) deletes bar even if foo is not readable

[Francis Galiegue]

On Wed, Feb 18, 2015 at 1:56 AM, Brian Burkhalter
<brian.burkhalter at oracle.com> wrote:
> Please comment at your convenience.
>
> Issue:  https://bugs.openjdk.java.net/browse/JDK-8073061
> Patch:  http://cr.openjdk.java.net/~bpb/8073061/webrev.00/
>
> Note that this is for now a RFC as opposed to a RFR. The copyright date of the affected file has not been updated, and there is no new test nor modification of an existing test specific to this change. The change does however pass the test provided in the issue description, and a JPRT job run on the usual suspect platforms with these options -testset core -onlytests '.*jdk_nio.*’ succeeds.
>
> I am not sure that this is the correct approach to take here and would prefer to hear some comment(s) before formalizing an RFR.
>
> The rationale for the change is to avoid deleting the target of the operation (copy(), move()) until the last possible opportunity. This is so that if something fails unexpectedly, the target of the operation will not be deleted in addition to the operation itself failing.
>
> I suppose there might be a much simpler way to address this which I would be happy to hear about.
>
> Thanks,
>
> Brian

OK, I'll bring my epsilon* euros/dollars here, but by reading the
patchset, I can't figure out what happens. As I see it, the process to
me is pretty simple, PROVIDED that the source is something from which
you can actually read a byte stream from (refer to my earlier report
about the source being a directory which triggered an IOException on
read only):

* try and open(2) the source for read; if EACCESS, AccessDeniedException;
* stat(2), or lstat(2) (if LinkOption.NOFOLLOW_LINKS is specified) the
source; if directory, try and rmdir(2); if it fails,
DirectoryNotEmptyException; if not directory, attempt and unlink(2);
* open(O_CREAT|O_EXCL) the destination;
* perform the copy.

Maybe this is what is actually done but from the patch set alone I
cannot tell that this is what actually happens...

Also, more generally, shouldn't it be guaranteed in the javadoc, when
this bug is fixed, that if ever the source is not readable, the
destination will be left intact?

-- 
Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa