@atripp Ahh ok, maybe that was what fixed it :)

Thank you

Hi @pmsensi , Can you take a look at this thread? https://forums.inedo.com/topic/5493/request-for-creation-of-api-for-package-auditing-before-dependency-restoration/7 I believe that new API proposal ( pgutil packages metadata) would contain that information -- please share your thoughts in that thread so we can keep it in one place. Thanks, Steve

Hi @wechselberg-nisboerge_3629 , Given how you uploaded the file, the only scenario that I could see this happening is if the file on disk is somehow corrupted. For example, if you were to locate one of the .rpm files on disk and change a few bytes with a hex editor, I would expect this exact error to occur. A feed reindex could would never fix this and obviously files cannot "heal themselves". However, this is exactly how hardware behaves, so I would look into that. Thanks, Steve

Hi @m-ruf_4197, Sure thing! I have added ticket PG-3115 to track the feature. It should be released within the next couple of maintenance releases of ProGet. Thanks, Rich

Hi @wechselberg-nisboerge_3629 , These specific errors would have no impact on performance, feed loading, nor would they cause ProGet to "break down" in any manner. And rebooting would most definitely not help, since they stem from bad/corrupt data. One possibility is that you have bad hardware - that causes peculiar and sporadic errors just like these that cannot be reproduced,. I can only imagine how frustrating this is, but your experience is atypical and without reproduction cases we really don't know how to help. I would focus on trying to reproduce -- if it's indeed "bad data" that you are uploading, it would happen every single time. Thanks, Steve

@albert-pender_6390 great news! And thanks for the heads up, I just updated the docs

Hi @wechselberg-nisboerge_3629, I'm not sure what I'm looking at in the screenshot, but it's most certainly not a piece of process memory. Based on the string literal, it's likely a compiled library (i.e. DLL) that's invoking methods in that system library; you'd need to study the contents in a hex view look for executable headers if you really wanted to know. Anyway, when it comes to downloading files, those are streamed directly from disk. In every instance of "corrupt downloads" that we've encountered, it was either due to network errors or hardware failures. And those are equally "impossible" to reproduce and nearly impossible to detect. I would just try new hardware, that usually does the trick. We see this quite a bit in cloud environments (Azure mostly, but every now and then AWS and GCP). Thanks, Steve

Hi @mmaharjan_0067 , It sounds like you're on the right track with researching this; your reverse proxy is definitely "breaking things" somehow. Based on what you wrote, it sounds like your reverse proxy is terminating the request because there's no output from the server after a while. The "no output" is expected, since assembling the upload takes quite some time, and that's likely where the "operation cancelled" would be coming from. I would look there and see if you can adjust timeouts. As for pgutil, here's the code used to perform the multi-part upload: https://github.com/Inedo/pgutil/blob/thousand/Inedo.ProGet/AssetDirectories/AssetDirectoryClient.cs#L197 -- Dean

Thanks for the further info - I'll make sure we retest with Server 2025.

Hi @shijiyong_6709 , This is a known limitation; when we implemented our Maven2 feed, we followed the 20+ year old Maven rule that "versions begin with numbers, artifacts begin with letters". Unfortunately there are some "ancient artifacts" and "broken versions" that don't follow this rule. Since ProGet is not just a "dumb file server", knowing whether Arabba-SR13 is a version or artifact is important - and it's a nontrivial effort to address these "bad" artifacts. We will consider doing that in the future but it doesn't seem to impact a lot of artifactsa nd hasn't been a priority Thanks, Steve

@atripp Hi Alana, I've just updated our clusters and replication to S3 with files greater than 2 GB in size works fine now. Thanks for giving this your attention!

@aristo_4359 thanks for letting us know! You are the first person to inquire about it over very many years :) We'll see if anyone else is interested in this and then we can consider adding it!

Hi @antonio-oliveira_8481 , We have already assessed the vulnerabilities; the container image is not susceptible to any of these vulnerabilities. Only two ports are exposed on the container (for http/https) and the overwhelming majority of packages built-in to the base container image (debian) are not used. Thanks, Steve

Hi @parthu-reddy , That image is not actually hosted on Docker Hub, but in MCR (mcr.microsoft.com). Confusingly, the Docker Hub is now used to "advertise" third-party containers in other registries, in addition to its own. In this case, there are no "tags" published on the docker hub page, so you know it's just an "ad" and not a real image Thanks, Steve

Hi @ashleycanham , This is a fairly complicated issue behind the scene, and is related to how these packages have multiple casings across different versions. This is something that should be addressed with PG-3100. After upgrading, you'll want to re-index the feed. If any packages still have incorrect casing, you can re-upload them to ProGet to correct the names. -- Dean

Hi, We upgraded to 2025.9 after testing in our dev environment and ProGet is now importing PyPi packages from the drop folder Thanks!

Hi @bohdan-cech_2403, ProGet can handle most invalid Maven version numbers, but Borca-SR2 is really invalid and isn't currently supported. Our "name vs version" parsing requires that versions start with numbers, artifacts start with letters. This has been a Maven rule for 20+ years now. It's non trivial and quite risky to change our parsing logic so it's not something we're keen on doing in a maintenance release. This scenario seems to be very rare and impact ancient artifacts and a few cases where authors didn't use Maven to deploy the artifacts. Thanks, Alana

@atripp thanks everything works with inedo/proget:25.0.10-ci.9

@gdivis That was the missing information (wait 30sec AND fetch repodata) - it works as described. To summarize what lead me to incorrectly assume that it was not fixed: My initial expectation was, it would be fixed by merely updating proget After that did not show progress, I found the repodata files in the feed storage path having an old timestamp Then I deleted and re-uploaded the latest rpm and noticed no timestamps change I never tried to actually fetch repodata, because I saw the old timestamps Thanks again for your clarification -Fritz