Valid entries returned by fetchDataset() in DatasetFSProvider for members and datasets that do not exist
Closed this issue · 4 comments
Describe the bug
According to the FileSystemProvider
wiki 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 FileSystemProvider
wiki 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:
{
name: 'NOTREAL'
ctime: 1729181444121,
mtime: 1729181444121,
isMember: true,
...
}
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):
- 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 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. - There are issues with how the dataset name is parsed if the URI is a member.
- The
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"]. - The dataset name passed to
mvsApi.dataSet()
is evaluated fromentryIsDir ? uriPath[0] : path.parse(uriPath[0]).name
. - If the entry does not already exist, meaning
entryIsDir
isfalse
, which results inpath.parse("REAL.PDS.NAME").name
. This results in"REAL.PDS"
being passed tomvsApi.dataSet()
.
- The
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 use mvsApi.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.
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.
Hi Benjamin,
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.
Thanks
@traeok Thanks for the quick reply. I am happy to open a PR, just thought I'd file an issue first. I will look into that scenario you mentioned.