Methods behave differently under Linux

[Krm1t]

Hello

edit: I just tried downgrading to version 5.0.0 and now things seem to work as expected.
It did of course require some changes to the code.

I'm unsure if i'm missing some linux related config or similar but i'm experiencing different behavior from various methods depending on whether i'm running on windows or linux.

Have reproduced this behavior in versions 6.0.2 and 6.0.3
running against the minio image: minio/minio:RELEASE.2024-04-18T19-09-19Z

I've attached a small project that tests BucketExistsAsync, GetObjectAsync and, PutObjectAsync.
Something as simple as BucketExistsAsync returns true whether or not the bucket exists.
I even found that if you use an invalid uri (say http://blablabla) when setting up the minio client, then BucketExistsAsync still work as if nothing is wrong - except that it takes longer because nothing is responding on that uri.

I tested against a Minio service running https, hosted in Kubernetes but docker-compose and http seem to work as well.
I recommend starting the minio container first and then open the web interface to create a bucket named "somevalidbucketname".
The name can be found and changed at the top of the Program.cs file.
Change the uri appropriately depending on whether running on your host (windows) or in the container (linux).
The swagger interface contains all 3 methods as simple get endpoints.
The test is more or less the same for all 3.
Call the endpoint and you should get a response back that shows the result (success) of the method called with both a valid and invalid bucket name.
For GetObject and PutObject you might also need to keep an eye on the log for console writeline messages.

On a side note: I ran into some bad behavior regarding exceptions being swallowed in the callback for GetObjectAsync.
I also happened upon some strange behavior with PutObjectAsync.
Do you want me to create separate issues for those?

Please let me know if you need anymore information or clarification.

MinioTest.zip

[ebozduman]

@Krm1t

This issue is a known problem from the previous release version 6.0.2 and a fix was introduced, tested and verified before 6.0.3 is released. So, it was supposed to be fixed in Minio version 6.0.3.
I also noticed the issue came back in 6.0.3 while testing the latest Minio package.
I am looking into it.
We'll use this issue to track it down.

[Krm1t]

@ebozduman Thanks for the quick response.
Am i correct in assuming that version 6.0.0 or 6.0.1 should work for now?
I'd rather not downgrade to 5.0.0 as it requires more changes to the code.

[ebozduman]

@Krm1t

Yes, you are correct. 6.0.1 should be fine as far as the BucketExistsAsync issue goes.
Correction: The regression was actually introduced in 6.01 (PR#995). So, you need to go back to 6.0

[ebozduman]

@Krm1t

Could you clarify it for me one more time: Did you see the issue on Windows only?
If so, what is your Windows version?
Although a similar behavior I've seen once yesterday in my Linux setup, I just cannot reproduce it anymore. I think it was due to a rare timing issue for the RemoveBucketAsync method I've used in my test case.

[Krm1t]

@ebozduman With regards to the version, we ended up downgrading to 5.0
In our testing that was the only one that seemed to work as expected - At least in the features that we use.

As for clarification: Running on Windows seem to work.
Our problems only occur when our code is running inside a docker container, which is running Linux.
I haven't tested RemoveBucket, only BucketExistsAsync, GetObjectAsync and, PutObjectAsync.

1. BucketExistsAsync : Always returns true, not matter what.
2. GetObjectAsync : Don't fail on errors (like if the object don't exist) but instead returns an empty (default) ObjectStat instance and the callback is never called.
   Side note: Exceptions inside the callback seem to get swallowed by minio rather than being propagated up to the the code that called GetObjectAsync.
3. PutObjectAsync : Seems to not upload the file to minio but also doesn't fail i.e. it looks like the file was uploaded successfully.

[ebozduman]

@Krm1t
I think PR #1141 has fixed several issues (duplicates) and this one.
I appreciate if you could test and verify the fix in your scenario.
Please let me know about your test results and findings.

[Krm1t]

@ebozduman Thanks for the update.
Unfortunately I can't promise that I'll be able to test it for now.
The client of the particular application is in the midst of some major infrastructure/hosting restructuring so currently any development is with the mindset of "if it ain't broke, don't fix it". Our next expected release is around March.
I might be able to test it now and then just have the update sit in a branch until we get closer to the next release.
I can't say though as i'm currently on holiday and don't know what the plans are going forward.