-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
oci os object put from STDIN not working in Cloud shell #490
Comments
I just tried in 3.4.0 and it worked fine. Could you try latest CLI? 16:34 $ oci --version 16:37 $ echo "my test" | oci os object put --bucket-name "$BUCKET_NAME" --name "Test1" --file - |
16:41 $ oci os object put --bucket-name "$BUCKET_NAME" --name "Test2" --file - <<<"my test" |
I tried on 3.4.0 on MacOS and was unable to repro the bug. I can repro on Linux (cloud shell) 3.3.2. That is the current version on cloud shell. Are you able to repro on 3.3.2. This bug results in silent data loss and so I regard as very serious. |
Normally Cloud shell lags by around 2 weeks to install latest version. Since this is not reproducible on latest CLI version, I would suggest installing latest version on CLI on Cloud shell using. bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)" https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm |
I just checked in 3.3.3 version and couldn't reproduce the error. Cloud shell is releasing 3.3.3 version. It should be updated in cloud shell soon. 10:06 $ oci --version |
Have you identified the code change that introduced this bug? I ask because it may have had an impact on other functionality, for example other commands that accept input from STDIN. I am puzzled that the unit test basic_cli_test_script.sh didn't detect this? |
Are you sure its a bug in 3.3.2 version as I couldn't reproduce it? Can you create a virtual env and install "pip install oci-cli==3.3.2" and try? (cli-3.3.2) ✘-1 ~ |
I have reproduced it on two different tenancies using cloud shell. is there some debug or trace I can set to isolate the problem? Have you tried to repro on cloud shell? |
this is from Cloud-shell: (cli-3.3.2) h_harsh_ku@cloudshell:~ (us-phoenix-1)$ oci --version |
So you were able to repro? Note, no "Uploading object part [####################################] 100%". |
The file "Test8" is uploaded. I have slacked you. Please message me there so that we can have a zoom. |
I tried uploading a file using STDIN on mac using 3.2.2 and 3.3.3 and 3.4.0 and it worked fine. But on Cloud shell, the uploaded file is 0 byte. (cli-3-4.0) h_harsh_ku@cloudshell:~ (us-phoenix-1)$ oci os object put --bucket-name Harsh-test --name "Test2" --file - <<<"my test" |
We are able to replicate the issue. We are root causing it. We will keep you posted. |
Uploading a file using STDIN on Cloudshell (oci os object put --bucket-name Harsh-test --name "Test2" --file - <<<"my test") leads to uploaded object of size 0 byte. This could result in data-loss without any error message on Cloud-shell. This issue is not been observed on other platforms ( Linux, Mac, Windows). As a workaround please use an actual file as an input while uploading (oci os object put --bucket-name Harsh-test --name "Test2" --file ). |
Issue was fixed in the latest release, 3.4.1. Cloud shell should have also updated the CLI version as well to latest. |
I am testing with oci cli 3.3.2. Here is a test script:
export BUCKET_NAME=bucket
awk 'BEGIN { srand(); print int(1 + rand() * 1000000)}'`oci os bucket create --compartment-id "$OCI_TENANCY" --name "$BUCKET_NAME"
TEXT="TextText"
oci os object put --bucket-name "$BUCKET_NAME" --name "Test1" --file - <<<"$TEXT"
echo -n "$TEXT" | oci os object put --bucket-name "$BUCKET_NAME" --name "Test2" --file -
echo "$TEXT" >TEXT_FILE
oci os object put --bucket-name "$BUCKET_NAME" --name "Test3" --file TEXT_FILE
for t in Test1 Test2 Test3; do
echo "$t:"
echo $(oci os object get -bn "$BUCKET_NAME" --name "$t" --file -)
done
`
Result (no errors) is:
`Test1:
Test2:
Test3:
TextText
`
The text was updated successfully, but these errors were encountered: