Reverting to 25.0.9 did actually work in our case So there seems to be some issue with 25.0.10

@stevedennis Re: Get package license with ProGetClient the pgutils packages metadata + API end point to be used in Inedo.Proget lib is what I need :) Do you have a timeline for the implementation ? Best Regards, Pedro

Hi @jfullmer_7346, It's nothing you did. The underlying issue is that a bug in ProGet allowed WinSCP (ID=563) to be added to the PackageNameIds table; that should never have happened since nuget is case insensitive. We've since fixed that bug. However, once you have a duplicate name, weird things happen since querying for "give me the PackageID for nuget://winscp" returns two results instead of one. So now when you query "give me the VersionID for (ID=563)-v6.5.3", a new entry is created. This has been a very long-standing issue, but there aren't any major consequences to these "weird things" except casing in the UI and the health check now fails. But we're on it :) Thanks, Alana

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

I have installed 25.0.10 release. I can't reproduce the error anymore.

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