Topics created by wechselberg.nisboerge_3629

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 @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 @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