[
https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17693239#comment-17693239
]
ASF GitHub Bot commented on MRESOLVER-329:
------------------------------------------
laeubi commented on code in PR #257:
URL: https://github.com/apache/maven-resolver/pull/257#discussion_r1117182543
##########
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##########
@@ -105,7 +106,16 @@ public Path getPath() {
@Override
public void move() throws IOException {
- Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+ try {
+ Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
Review Comment:
As mentioned in the other PR this is likely not what one wants. If the
(atomic) move do not succeeds, there is no guarantee that the file has not
changed (deleted, modified, ...) so retry the move will simply ignore this and
overwrite everything. So callers of the move operation must retry the full
operation.
> Make IO in DefaultTrackingFileManager more robust
> -------------------------------------------------
>
> Key: MRESOLVER-329
> URL: https://issues.apache.org/jira/browse/MRESOLVER-329
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
> Reporter: Tamas Cservenak
> Assignee: Tamas Cservenak
> Priority: Major
> Fix For: 1.9.6
>
>
> There are couple of spots where implementation naively assumes is alone
> running process on this world. Several user reports suggests this is not the
> case, like MRESOLVER-325 or MNG-7705. Fix these spots.
> Still, something is fishy, as it seems these files (all that are handled by
> DefaultTrackingFileManager) are not subject to locking? This needs
> investigation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
