Fix UnArchiver#isOverwrite not working as expected #229
Conversation
Regression in efd980d changed the way UnArchiver#isOverwrite flag work. It is indented to indicate that UnArchiver should always override the existing entries. efd980d changed it to indicate whether existing file should be overridden if the entry is newer, while in this case the file should be always overridden. This commit returns the old behavior: if the entry is newer, override the existing file; if the entry is older, override the existing file only if isOverwrite is true. Fixes: #228
![sonatype-lift[bot]](https://avatars.githubusercontent.com/in/9843?s=60&v=4){kind=small}
|
@mthmulders do you recall if there was some specific use case that caused the change in behavior, or maybe it was caused by confusion because of this comment - #128 (comment) |
It's been a while, @plamentotev... I don't recall exactly - that particular PR had been open for almost a year when the comment was added, and I do recall that I was confused by it. I am afraid the confusion may have let to an unintended change of behaviour, but I cannot say for sure. It might be good to check if this (partial) has any effect on the Maven Dependency Plugin, in particular the situation described in MDEP-651. |
|
@mthmulders, thanks for the reply.
I'm not sure I follow you on this one. It would not affect the warning - it would always show it if there is existing file on the file system that is with different casing (e.g readme and README). But the content of the file after this change may be different as the override rules are changed. My understanding is that MDEP-651 is about showing the warning and the content does not matter because in both cases (file is overridden or not) the content is corrupted, right? Or I'm missing something and for example README should never override readme? |
Regression in efd980d changed the way
UnArchiver#isOverwriteflag work.It is indented to indicate that
UnArchivershould always override the existing entries.efd980d changed it to indicate whether existing file should be overridden if the entry is newer, while in this case the file should be always overridden.
This commit returns the old behavior: if the entry is newer, override the existing file; if the entry is older, override the existing file only if isOverwrite is true.
Fixes: #228