Error encountered when saving USS file

[mmoore96]

Describe the bug

When I am using trying to save a USS file, it throws an error saying:
Zowe Explorer FTP Extension: Rest API failure with HTTP(S) status 412

I then have to continuously attempt to save the file, until finally it saves. It usually takes 5-10 'saves' before it is successful.

I have not experienced this issue with Data Sets.

It was fine prior to the release of v1.22.0

To Reproduce

Expected behavior

After editing the USS File, it should be saved on the first attempt.

Screenshots

Log

[2022/04/05 16:08:00.529] [ERROR] [extension.js:73] Error encountered when saving USS file: {}

Desktop (please complete the following information):

• OS: Microsoft Windows 10 Enterprise
• Zowe Explorer Version: v1.22.0
• Zowe CLI Version: 6.37.2
• Are you using Secure Credential Store? No

Additional context

n/a

[github-actions]

Thank you for creating a bug report. If you haven't already, please ensure you have provided steps to reproduce it and as much context as possible.

[tiantn]

Thank you @mmoore96. I can see the message when the saved content conflict with file in mainframe. Could you help to check if your file is conflict with file in mainframe? Thank you!
And though the message is expected when the conflict happened the message now is not clear. So we will update the error message to make it clear and meaningful. Thank you!

[mmoore96]

Hello, @tiantn,
From best I can tell, the only conflict is the changes I have made to uss file. But I would not think that would cause an error.
At no point, was a change made to the file on the mainframe, only via Zowe.

This morning, I tried to edit a .java file. I got the Rest api failure.
I then right clicked on the file and selected 'pull from mainframe.' I made the change and it was saved successfully.
I made another change and got the Rest api failure again.

Other devs at my work also have experienced the same thing. We are switching to z/OSMF soon so this will not long be an issue as I supposed this has to do with Zowe using ftp.

Note:
Occasionally, it appears after I try to open a .class file by mistake (not 100% as this morning I only opened a .java class and still had the issue with saving). Zowe explorer will attempt to get the .class file but will stop and prompt if I would like the binary. I ignore this.
Also, sometimes in the bottom left it will display "opening file" in perpetuity. Only way to stop this is to close VS Code.
I can open another issue for this problem.

I hope this helps!

[tiantn]

Hi @mmoore96 , thank you for the details. I think I recreate the situation now. I do the following:

• create a uss file with .java name
• edit the file and save it. // upload succeessfully
• edit the file again and save it. // error send
• pull from mainframe.
• edit the file again and save it. // upload succeessfully

I found the issue caused by the conflict of line ending setting. In vscode, the default setting is LF, and when saved it to mainframe, the line ending is change to CRLF.

The setting in vscode when I edit:

The setting after I pull from mainframe:

To verify the guess, I set it to CRLF before I first save it. Then I edit the file again and save it. It saved successfully.

I also try the .txt file, no same error found. Maybe we need pay more attention on special type of files when edit them.

If you are convenient could you help to verify on your environment with CRLF ? Thank you very much!

[mmoore96]

Thank you, @tiantn, for doing this research.
I have recreated what you did. It saved successfully once after changing the line ending setting from LF to CRLF. After that, any changes result in an error.
To note, I have been using CRLF as my default for a while now.

In conclusion:

• Going from LF to CRFL results in a successful save only once (next edit throws error).
• Going from CRFL to LF makes no difference and will throw an error.

The only way to save successfully is by entering Cntl + S until no error is thrown and the file is saved.

I also get the same error with .txt files.

This only happens in USS not with Datasets.

[tiantn]

Thank you @mmoore96.
I investigated the implementation of uploading USS file and dataset. The uss file etag update logical seems missing update to latest etag. I changed this part to be consistent with dataset part. It works well now. Could you help to try it? Thank you!
#1768

[tiantn]

Sorry, I just want to relate the problem to the PR. Not aware it is closed.

[mmoore96]

@tiantn
Thank you for making this fix.
I was able to build the pre-production Zowe master and test it my-self.
It is working so much better. I am not longer getting as many errors.

However, there is an edge case in which you can still throw an error that is not expected:

1. Open a .java file
2. Make an edit and save it (which is successful).
3. Right click on the .java file in the USS section and select "Pull from Mainframe."
4. Edit the .java file again and save it. <----This results in a merge conflict error (used to be 412 error)

You can select "Pull from Mainframe" again and then try to make an edit and it will save successfully.

As a user, I should not have to pull from the mainframe in order to avoid this error. This causes my code changes to be removed and is a headache.

I do understand that there is a chance someone else has made a change to the file since your last pull. However, in my experience there is quite rare unless two people are working on the same file which does not happen very often. We have our own directories/pds' that we edit our own version of a program in. You could argue that if the same user used tn3270 to make a change then went back to zowe and started writing code then that would be problematic. However, the user should know that they need to pull from mainframe first.

I think a good solution to fix this problem would be to ask to user if they would like to override the save conflict.

Thank you!