Files.copy() under Linux at least will remove the existing destination even if the source cannot be read...

[Francis Galiegue]

On Wed, Feb 11, 2015 at 10:58 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 11/02/2015 21:40, Francis Galiegue wrote:
>>
>> :
>> Not sure what you mean by "test the source file" here. Test its
>> existence? That read access is granted?
>
> It stats the file to check it exists and to see the file type. This isn't
> good enough here.

OK well, I did open the bug but via the official channel. I did create
an account on openjdk.java.net and could not submit a bug via this
channel :/

>>
>>
>> Note: I had someone run the code on a Windows machine and in this case
>> the destination file was left intact, as, well, expected; except that
>> the documentation of Files.copy() itself indeed makes no guarantee as
>> to the integrity of the destination file in such a scenario :/
>>
> The Windows implementation is very different but it should be craft an ACL
> to get similar behavior.
>

Well, in any event, it behaves "as expected", I'd say...

>
> Yes on the javadoc, it doesn't make any guarantees for when it fails.
>

Shouldn't it? I mean, don't you agree that this is a pretty fundamental issue?

To be brutally honest, I am very surprised that this test case was not
even considered; it is a pretty plausible scenario...

-- 
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