[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[ https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792946#comment-17792946 ] ASF GitHub Bot commented on MRESOLVER-329: -- cstamas closed pull request #260: [MRESOLVER-329] More robust IO in default tracking file manager URL: https://github.com/apache/maven-resolver/pull/260 > 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 > > 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)
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[ https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695574#comment-17695574 ] Tamas Cservenak commented on MRESOLVER-329: --- Not for 1.9.6, we need deeper analysis. > 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 > > 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)
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[ https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693990#comment-17693990 ] ASF GitHub Bot commented on MRESOLVER-329: -- michael-o commented on PR #260: URL: https://github.com/apache/maven-resolver/pull/260#issuecomment-1446227239 Before we merge this, I'd like to see Jim's data first. > 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)
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[ https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693978#comment-17693978 ] ASF GitHub Bot commented on MRESOLVER-329: -- cstamas commented on PR #257: URL: https://github.com/apache/maven-resolver/pull/257#issuecomment-1446192026 Superseded by https://github.com/apache/maven-resolver/pull/260 > 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)
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[ https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693979#comment-17693979 ] ASF GitHub Bot commented on MRESOLVER-329: -- cstamas closed pull request #257: [MRESOLVER-329] More robust IO in DefaultTrackingFileManager URL: https://github.com/apache/maven-resolver/pull/257 > 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)
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[ https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693977#comment-17693977 ] ASF GitHub Bot commented on MRESOLVER-329: -- cstamas opened a new pull request, #260: URL: https://github.com/apache/maven-resolver/pull/260 In case of concurrent r/w of tracking file, the if Files.isReablable may return true, but the file might be gone once it arrives to Files.newInputStream. In these cases, just ignore the missing file related exception. --- https://issues.apache.org/jira/browse/MRESOLVER-329 > 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)
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[ https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693894#comment-17693894 ] Michael Osipov commented on MRESOLVER-329: -- [~cstamas], any objections to close this out? > 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)
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[ https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693707#comment-17693707 ] Michael Osipov commented on MRESOLVER-329: -- I'd like to supersede this with MRESOLVER-331. > 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)
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[ https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693550#comment-17693550 ] ASF GitHub Bot commented on MRESOLVER-329: -- michael-o commented on PR #257: URL: https://github.com/apache/maven-resolver/pull/257#issuecomment-1445224171 Does not work and suffers from the chicken and egg problem described in here: https://issues.apache.org/jira/browse/MRESOLVER-325?focusedCommentId=17693545=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17693545 > 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)
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[
https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693549#comment-17693549
]
ASF GitHub Bot commented on MRESOLVER-329:
--
michael-o commented on code in PR #257:
URL: https://github.com/apache/maven-resolver/pull/257#discussion_r1117990047
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultTrackingFileManager.java:
##
@@ -75,6 +76,8 @@ public Properties update(File file, Map
updates) {
if (Files.isReadable(filePath)) {
try (InputStream stream = Files.newInputStream(filePath)) {
props.load(stream);
+} catch (NoSuchFileException e) {
+// MRESOLVER-329: ignore; in case of concurrent r/w
Files.isReadable may return true
Review Comment:
Please move this to another PR, both issues aren't necessarily related.
##
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);
+} catch (AccessDeniedException e) {
+// MRESOLVER-329: fallback to plain copy+rm, this usually
happens on Windows
Review Comment:
MRESOLVER-325 and not 329
> 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)
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[ https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693282#comment-17693282 ] ASF GitHub Bot commented on MRESOLVER-329: -- michael-o commented on PR #257: URL: https://github.com/apache/maven-resolver/pull/257#issuecomment-1444066052 I'd like better understand whether the usecases file w/o temp files. I want to exclude our locks to be faulty here. > 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)
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[
https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693253#comment-17693253
]
ASF GitHub Bot commented on MRESOLVER-329:
--
cstamas commented on code in PR #257:
URL: https://github.com/apache/maven-resolver/pull/257#discussion_r1117219091
##
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:
I might be wrong, but this is what Jenkins does as well: tries atomic, and
if fails, the fallback is plain copy+rm... Naturally, this will need some
triage, to see is it working at all. Also, all this is for only one: Windows
> 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)
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[
https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693252#comment-17693252
]
ASF GitHub Bot commented on MRESOLVER-329:
--
cstamas commented on code in PR #257:
URL: https://github.com/apache/maven-resolver/pull/257#discussion_r1117219091
##
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:
I might be wrong, but this is what Jenkins does as well: tries atomic, and
if fails, the fallback is plain copy+rm... Naturally, this will need some
triage, to see is it working at all.
> 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)
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[
https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[ https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693229#comment-17693229 ] ASF GitHub Bot commented on MRESOLVER-329: -- cstamas opened a new pull request, #257: URL: https://github.com/apache/maven-resolver/pull/257 Make the code more robust to copy with concurrently accessed files and hopefully with Windows quirks re atomic move. --- https://issues.apache.org/jira/browse/MRESOLVER-329 > Make IO in DefaultTrackingFileManager more robust > - > > Key: MRESOLVER-329 > URL: https://issues.apache.org/jira/browse/MRESOLVER-329 > Project: Maven Resolver > Issue Type: Improvement >Reporter: 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)
