Quick breeze, it LGTM, and happy green test buttons to boot!

really quick pass LGTM ... hopefully someone can walk through a little slower than today allowed.

Based on benchmark results, I disabled this improvement for WSL. I rebenchmarked this improvement on Windows 11 and it didn't get better, but overall CPU usage is lower. Let me know if you think disabling this feature for WSL makes sense.

Benchmark report

PTAL:@Luap99@baude@TomSweeneyRedHat@mheon

Unrelated CI failure; fixed in#27562

LGTM
but I'd like a head nod or two from folks more familiar with macOS and Windows than I.

PTAL@l0rd

@Honny1 I have tested with hyper-v but I cannot see any difference in terms of perfs. I will look at it closer tomorrow.

I reran that on Windows 11 and Hyper-V, and the results are the same;here is the report. I observed performance changes depending on the resources allocated to the Podman machine. I think I can set up an experiment to test different combinations, specifically comparing 2GB vs. 8GB of memory. Also, I am running these benchmarks on older hardware.

WDYT?@l0rd

Benchmark Report (hyperv)

The problem was on my side. I didn't replace the podman service in the machine. Now I have fixed that and I can see the improvemnts in perfs (5s vs 65s!) and I have also quickly verified that a file in a drive that is not mounted in the machine is correctly copied (and is slower as expected).

LGTM on the Hyper-V side. I can have a look on WSL too if you want.

That would be great to verify if WSL can benefit from newer hardware. Don't forget to build from source and drop the latest commit from this PR. (It disables this feature for WSL.)

I confirm that on WSL, there is no performance difference before/after if I use the last commit of this PR (11s vs 5s with HyperV). But I get the same performances using commit2f7094c too:

> .\bin\windows\podman versionClient:       Podman Engine....Git Commit:   2f7094c0dea104703c9adb9aedc505e503d34c42-dirty....Server:       Podman Engine...Git Commit:   2f7094c0dea104703c9adb9aedc505e503d34c42...>Measure-Command { ./bin/windows/podman artifact add quay.io/myartifact/benchmark:latest ./artifacts/random-file }Days              :0Hours             :0Minutes           :0Seconds           :11Milliseconds      :933Ticks             :119333670TotalDays         :0.000138117673611111TotalHours        :0.00331482416666667TotalMinutes      :0.19888945TotalSeconds      :11.933367TotalMilliseconds :11933.367> wsl--versionWSL version:2.6.1.0Kernel version:6.6.87.2-1WSLg version:1.0.66MSRDC version:1.2.6353Direct3D version:1.611.1-81528511DXCore version:10.0.26100.1-240331-1435.ge-releaseWindows version:10.0.26200.7171

This indicates that on faster computers, this operation can perform similarly. I would still keep this feature disabled for WSL.

[APPROVALNOTIFIER] This PR isAPPROVED

This pull-request has been approved by:Honny1,l0rd

The full list of commands accepted by this bot can be foundhere.

The pull request process is describedhere

Out of curiosity (and It's not something introduced by this PR anyway), but why do we require the artifact path to be absolute?

The local API facilitates path translation from client to server for convenience. Mounted host directories mimic the host's absolute paths, so a path on the host matches the path inside the VM (with a small exception for Windows, whereC:\\ translates to/mnt/c/). Consequently, users utilizing the Podman client do not need to strictly use absolute paths. This is standard behavior across all local APIs.