Files.copy() under Linux at least will remove the existing destination even if the source cannot be read...
Francis Galiegue
fgaliegue at gmail.com
Wed Feb 11 23:50:48 UTC 2015
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
More information about the nio-dev
mailing list