[
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17837603#comment-17837603
]
ASF GitHub Bot commented on MRESOLVER-536:
------------------------------------------
cstamas commented on code in PR #469:
URL: https://github.com/apache/maven-resolver/pull/469#discussion_r1566975286
##########
maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java:
##########
@@ -691,8 +690,7 @@ public void handle(CloseableHttpResponse response) throws
IOException, TransferC
if (lastModifiedHeader != null) {
Date lastModified =
DateUtils.parseDate(lastModifiedHeader.getValue());
if (lastModified != null) {
- Files.setLastModifiedTime(
- task.getDataFile().toPath(),
FileTime.fromMillis(lastModified.getTime()));
+
task.getDataFile().setLastModified(lastModified.getTime());
Review Comment:
@rmannibucau As I told to @michael-o , I find this proposal futile, and here
is why: user @Jurrie spotted this problem ONLY HERE as this was the only one
spot using method that throws (`Files.setLastModified`). If you look at master
PR https://github.com/apache/maven-resolver/pull/468 it will show you all the
places where time mtime is set (as master was ported from `File` to `Path`). So
all those place will not log anything and are "forgiving" when they try but
fail to set mtime, and hence, logging it only here makes no sense IMHO. If you
want, you can make a PR for 1.9.x that sweep changes all `File.setLastModified`
usages and logs something at TRACE, but I find it useless change (as it never
logged that so far).
> Skip setting last modified time when FS does not support it
> -----------------------------------------------------------
>
> Key: MRESOLVER-536
> URL: https://issues.apache.org/jira/browse/MRESOLVER-536
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
> Affects Versions: 1.9.18
> Reporter: Jurrie Overgoor
> Assignee: Tamas Cservenak
> Priority: Major
> Fix For: 2.0.0, 1.9.19, 2.0.0-alpha-11
>
> Attachments: Stacktrace.txt
>
>
> When Maven resolver downloads a file and writes it to disk, it tries to set
> the last modified time on it. There are filesystems that do not support the
> "set last modified time" operation. In that case the operation will fail, and
> the Maven build will error out with a {{FileSystemException}}. Attached is
> (the last part of) such a stack track trace.
> I encountered such a file system when running in a Kubernetes (Openshift
> actually, but that's Kubernetes based) cloud setup. I mapped the {{~/.m2}}
> directory to a Persistent Volume Claim so that files downloaded in one build
> are retained in the next build. I explicitly set the access mode to
> ReadWriteMany (a.k.a. RWX, a.k.a. Shared Access) so that multiple build nodes
> can use the same PVC. The PVC is provisioned by a [`file.csi.azure.com`
> provisioner|https://learn.microsoft.com/en-us/azure/aks/azure-files-csi]. And
> that translates to a file system that does not support setting the last
> modified time on a file. Thus the call to
> {{java.nio.file.Files.setLastModifiedTime(Path, FileTime)}} in
> {{org.eclipse.aether.transport.http.HttpTransporter.EntityGetter.handle(CloseableHttpResponse)org.eclipse.aether.transport.http.HttpTransporter.EntityGetter.handle(CloseableHttpResponse)}}
> comes crashing down.
> There is no good way to query if the FS supports the call. So I resorted to
> wrapping the call in a `try .. catch` block. This seems to work. Maven
> downloads dependencies again, and my build progresses.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
