You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the FileSystemProviderwiki page, you can call the vscode.workspace.fs.stat function with a Zowe URI containing the fetch=true query and Zowe Explorer will attempt to lookup the resource URI. The wiki claims that ZE will only return a valid entry if it exists on the remote system, but I am seeing valid entries returned when I request members or data sets that do not exist. I believe DatasetFSProvider.fetchDataSet() is causing these issues. See additional context for specific info.
To Reproduce
For extenders to fetch resources on demand using the new v3 file system, we are recommended to do something similar to the following approach (copied from FileSystemProviderwiki page):
// When this URI is opened, Zowe Explorer will attempt to fetch the MEM member in the EXAMPLE.PART PDS if it does not already exist.
let pdsMemberUri = vscode.Uri.from("zowe-ds:/lpar.zosmf/EXAMPLE.PART/MEM?fetch=true");
try {
const fsEntry = await vscode.workspace.fs.stat(pdsMemberUri);
// optional: remove the fetch query after a successful `stat` call as its no longer needed.
pdsMemberUri = pdsMemberUri.with({ query: "" });
} catch (err) {
// an error occurred while trying to fetch the resource; return.
console.log(err);
return;
}
Try using a member name that does not exist. I tested await vscode.workspace.fs.stat() with a member URI such zowe-ds:/validprofile/REAL.PDS.NAME/NOTREAL?fetch=true. What is returned is a FileStat object for a member that does not exist:
I expect a vscode.FileSystemError.FileNotFound(uri) to be thrown if the resource does not exist, which extenders can catch and handle appropriately.
Screenshots
Desktop (please complete the following information):
OS: MacOS
Zowe Explorer Version: 3.1.0-SNAPSHOT (using the main branch in the debugger)
(Optional) Zowe CLI Version:
(Optional) Are you using Secure Credential Store?
Additional context
There are problems I see with the implementation of fetchDataset() that I believe are causing these problems.
We only use mvsApi.dataSet() to check if the resource does not exist or not. If the URI is referring to a member, we need to check the members of the PDS, not the PDS itself.
There is an opportunity to throw a vscode.FileSystemError.FileNotFound(uri) on line 213 of DatasetFSProvider, but it is practically never hit because it only throws the error if the mvsApi.dataSet() API call was unsuccessful. It is important to note that a successful dataSet() call does not mean a dataset or member exists with that name. We need to check the resp.apiResponse.items to know that. Just checking if the response was successful does not tell us anything about the existence of the resource. mvsApi.dataSet() is successful even if the resource does not exist.
There are issues with how the dataset name is parsed if the URI is a member.
The uriPath variable on line 203 will be an array of two items if it is a member (from the example above, it is `["REAL.PDS.NAME", "NOTREAL"].
The dataset name passed to mvsApi.dataSet() is evaluated from entryIsDir ? uriPath[0] : path.parse(uriPath[0]).name.
If the entry does not already exist, meaning entryIsDir is false, which results in path.parse("REAL.PDS.NAME").name. This results in "REAL.PDS" being passed to mvsApi.dataSet().
Everything works great if the resource exists (as is basically guaranteed when using the Zowe Explorer tree views). Open to feedback on my branch. I can open a PR and add unit tests. Please let me know if I am missing something and if there is not actually a problem.
The text was updated successfully, but these errors were encountered:
Thank you for creating a bug report.
We will investigate the bug and evaluate its impact on the product.
If you haven't already, please ensure you have provided steps to reproduce the bug and as much context as possible.
The details that you mentioned above make sense to me. My only concern is that "if the resource exists" means that this may break remote lookup of data sets after reopening Zowe Explorer. I'll take a look at your fork and will test to see how this behaves. As always, all contributions are welcome, so feel free to contribute a fix. If you have any questions please let me know.
Describe the bug
According to the
FileSystemProvider
wiki page, you can call thevscode.workspace.fs.stat
function with a Zowe URI containing thefetch=true
query and Zowe Explorer will attempt to lookup the resource URI. The wiki claims that ZE will only return a valid entry if it exists on the remote system, but I am seeing valid entries returned when I request members or data sets that do not exist. I believeDatasetFSProvider.fetchDataSet()
is causing these issues. See additional context for specific info.To Reproduce
For extenders to fetch resources on demand using the new v3 file system, we are recommended to do something similar to the following approach (copied from
FileSystemProvider
wiki page):Try using a member name that does not exist. I tested await
vscode.workspace.fs.stat()
with a member URI suchzowe-ds:/validprofile/REAL.PDS.NAME/NOTREAL?fetch=true
. What is returned is aFileStat
object for a member that does not exist:Expected behavior
I expect a
vscode.FileSystemError.FileNotFound(uri)
to be thrown if the resource does not exist, which extenders can catch and handle appropriately.Screenshots
Desktop (please complete the following information):
main
branch in the debugger)Additional context
There are problems I see with the implementation of fetchDataset() that I believe are causing these problems.
mvsApi.dataSet()
to check if the resource does not exist or not. If the URI is referring to a member, we need to check the members of the PDS, not the PDS itself.vscode.FileSystemError.FileNotFound(uri)
on line213
ofDatasetFSProvider
, but it is practically never hit because it only throws the error if themvsApi.dataSet()
API call was unsuccessful. It is important to note that a successful dataSet() call does not mean a dataset or member exists with that name. We need to check theresp.apiResponse.items
to know that. Just checking if the response was successful does not tell us anything about the existence of the resource.mvsApi.dataSet()
is successful even if the resource does not exist.uriPath
variable on line203
will be an array of two items if it is a member (from the example above, it is `["REAL.PDS.NAME", "NOTREAL"].mvsApi.dataSet()
is evaluated fromentryIsDir ? uriPath[0] : path.parse(uriPath[0]).name
.entryIsDir
isfalse
, which results inpath.parse("REAL.PDS.NAME").name
. This results in"REAL.PDS"
being passed tomvsApi.dataSet()
.I tried fixing the behavior on a branch in my own fork: https://github.com/benjamin-t-santos/zowefork/tree/datasetfsprovider-remote-lookup-fix. I check the actual
apiResponse
to see if the data set or member exists, I usemvsApi.allMembers()
to check if a member exists, and I tried to fix how the dataset name is parsed.Everything works great if the resource exists (as is basically guaranteed when using the Zowe Explorer tree views). Open to feedback on my branch. I can open a PR and add unit tests. Please let me know if I am missing something and if there is not actually a problem.
The text was updated successfully, but these errors were encountered: