Open benjamin-t-santos opened 3 hours ago
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-t-santos,
If you call readDirectory
with the PDS URI first, and then read one of its members using readFile
, does this solution work for you?
We try to avoid fetching extra resources as a part of readFile
, but we can expand it to fetch other PDS members during the remote lookup if needed.
Calling readDirectory
with the PDS URI first and then reading one of its members using readFile
works, but that is not the approach that I want to take. A PDS can have 1000s of members - creating 1000s of entries is slow when I ultimately use readFile
to get the contents for just one or two members I need.
I am not requesting readFile
to fetch extra resources during the remote lookup - just the member I requested. It is my understanding that if the data set or member exists on the host, readFile()
should return its contents, including fetching the requested resource and creating an entry for it if needed. Currently, it does not always do that.
That's fair - in that case I think we should go with option 1.
As an alternative, you could call stat
with fetch=true
to populate the member and then use readFile
to fetch its contents - but I still think this case w/ PDS members should be handled for consistency.
I was calling stat() + readFile() as you suggested originally, but just readFile() is a bit faster as it avoids the "stat is locating resource" step. When fetching lots of members, it can add up.
Describe the bug
According to the
FileSystemProvider
wiki page, you can callvscode.workspace.fs.readFile(pdsMemberUri)
to check if a member exists. If it does, its contents are returned. If it does not, aFileNotFound
error is thrown. With the current implementation ofreadFile()
, however, checking multiple members from the same PDS will incorrectly throwFileNotFound
errors for every member after the first member is checked. Explanation of why in "Additional Context". To Reproducezowe-ds:/profile/PDS.NAME/MEMBER1
,zowe-ds:/profile/PDS.NAME/MEMBER2
vscode.workspace.fs.readFile
with both URIsMEMBER1
will have its contents returned, the call withMEMBER2
throws error:EntryNotFound (FileSystemError): zowe-ds:/profile/PDS.NAME/MEMBER2
Expected behavior
Contents for both members are returned.
Screenshots
Desktop (please complete the following information):
main
branchAdditional context
readFile()
is called, ZE starts by trying to find an existingDsEntry
for the provided member URI.parent
of the provided member URI.null
, we fetch the resource from remote and create entries for theparent
and the member URI (all done infetchDataset()
)All that behavior is okay. Now we call
readFile()
with a second member of the same PDS.readFile()
is called, ZE starts by trying to find an existingDsEntry
for the second member.fetchDataset()
is never called)ds
variable never gets set to an entry, so an error is thrown on line401
Proposed solution: Do not always assume an entry for a member exists if its parent's entry exists. This is a fair assumption if you are using the tree views (I am assuming opening a PDS creates entries for its members), but the same guarantee does not exist for extenders.
Two potential options:
fetchDataset()
will return without making any calls to remote and just return the value ofthis.lookup(uri)
fetch=true
query forreadFile()
like we can forvscode.workspace.fs.stat()
. When checking the parent, we can check for thefetch
query in the same conditional. Something likeif (parent == null || queryParams.has("fetch"))
Happy to open a PR, but wanted to open an issue to discuss a) whether we want to support this and b) what approach is preferred