[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 9:08 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 18/02/2015 07:30, Francis Galiegue wrote:
>>
>> On Wed, Feb 18, 2015 at 7:56 AM, Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>> [...]
>>>
>>> copy & move are complicated as it requires dealing with many different
>>> file
>>> types, sym links, etc. For the regular file case and when overwriting an
>>> existing file then it needs to truncate the existing file rather than
>>> deleting it (that is what this bug is about).
>>>
>> Hold on. Are we talking about the same thing?
>>
> Yes, we are talking about the same thing. There is big matrix of scenarios
> but for the scenario in the bug report then the source should be opened for
> reading, then the destination gets opened. There are several other scenarios
> where you can't do this of course.
>

This was not what I was talking about.

>From your mail I understood that the destination file would have to be
opened(O_TRUNC) _even if the source file is not readable_. Which is
not any better than the current behavior, really. In fact it's even
worse.

Or did I misread?

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