What version of iSphere do you use? I cannot reproduce the problem. Instead I found another problem that I have fixed, now.
Figure #1 shows all files that I had added to my folders. It also shows the problem that I have found and fixed. The problem was that no files could ever go "through" the filter unless the filter was set to "*". Now it works fine.
Figure #2 shows the IFS filter selecting only *.log files. For me that looks well. Only the log files are displayed in the iSphere search dialog.
Please let me also know the RDi version that you use.
I'm using RDi version 9.8.0.1 (20231214_1238) and iSphere version 5.2.9.r
I did find that the file list in the search dialog is correctly filtered if the *.log filter is the first one I use.
These steps reproduce the problem on my system:
Start RDi and connect
Run an iSphere stream file search on a filter limited to file name *.log --> only log files are shown
Run an iSphere stream file search on a filter limited to file name * --> all files are shown
Run an iSphere stream file search on a filter limited to file name *.log --> all files are shown
It does seem to be limited to searches on the same IFS folder. If step 3 is done on a different (sub)folder, step 4 only shows log files. The * and *.logs filters are identical except for the file name part.
Could it be a cache issue?
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please re-test that with a new workspace. I had the problem that RDi updated 2 filters when I changed one of them in my workspace. The problem vanished, after I had deleted and re-created the filters. From then on I could not re-produce the problem.
I am relatively sure that it is not an iSphere problem. Last but not least there is no caching by iSphere.
Thomas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I finally figured it out. Here are the steps to reproduce the problem:
1) Create a new IFS filter for log files only (*.log).
2) Create a new filter (same path as #1) for all files (*).
3) Restart RDi, e.g. File -> Restart
It is essential to create the Log Files Only filter first, followed by the All Files. I already reported the problem to IBM.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Exactly. I did it again. First I created the "All Files" filter and then the "Log Files Only" one. After restarting RDi, the filters work as expected.
And to be sure for 100% I created a new workspace and started over. Same result.
Thomas,
the filters themselves works as expected, they show all files or only the log files.
However, if I right-click a subfolder in a filter and choose "iSphere Stream File Search", it will show all files in the folder even if I use the log files filter. But only if I run a search on the all files filter first.
Also I noticed that the search is only done for files in the folder itself, not in subfolders. Don't know if this is by design? I don't see a "include files in subfolders" checkbox.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good to know that we are now at the core of the problem.
The problem is that I do not have any information about the filter if the user selected an item below the filter entry. In such cases Eclipse provides an IFSRemoteFile object, which has no knowledge about whatever filter it is related to. Therefore the only thing iSphere can do is get the path from the selected entry and start a search from there with no restrictions. By the way that is the reason for the additional "Stream file type" filter on the search dialog. Figure: debugger-folder-selected.png
That is missing in the help text.
In the other case of that a filter is selected for the iSphere search, Eclipse returns a SystemFilterReference object with all the information of the filter. Figure: debugger-filter-selected.png
IFS directories can grow fairly large and hence I restricted the depth to the current (selected) directory and its direct children (= one level down).
It is in the help:
"Note: For now iSphere stream file search is restricted to resolve subdirectoriesdown to 1 level, because IFS directory trees may be extremely large."
Of course I could add a switch for removing that restriction. But is that really a good idea? The amount of data returned could be very large. Another option would be to specify a maximum number of elements to read. Resolving the directory tree would take the same time (from the first to the very last element) but the number of elements returned could not exceed a given maximum.
Hi Peter,
The problem that filtering for a type on the iSphere search dialog clears the list, is the bug that I mentioned above and that I fixed in iSphere 6.0.4, which I released a few minutes ago.
I agree, that it may be good to restrict the number of items returned to a reasonable default value that could be changed by the user. I assume we will see that in the next version.
Thomas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Peter,
What version of iSphere do you use? I cannot reproduce the problem. Instead I found another problem that I have fixed, now.
Figure #1 shows all files that I had added to my folders. It also shows the problem that I have found and fixed. The problem was that no files could ever go "through" the filter unless the filter was set to "*". Now it works fine.
Figure #2 shows the IFS filter selecting only *.log files. For me that looks well. Only the log files are displayed in the iSphere search dialog.
Please let me also know the RDi version that you use.
Thomas.
Hi Thomas,
I'm using RDi version 9.8.0.1 (20231214_1238) and iSphere version 5.2.9.r
I did find that the file list in the search dialog is correctly filtered if the
*.logfilter is the first one I use.These steps reproduce the problem on my system:
*.log--> only log files are shown*--> all files are shown*.log--> all files are shownIt does seem to be limited to searches on the same IFS folder. If step 3 is done on a different (sub)folder, step 4 only shows log files. The
*and*.logsfilters are identical except for the file name part.Could it be a cache issue?
Peter
Hi Peter,
Please re-test that with a new workspace. I had the problem that RDi updated 2 filters when I changed one of them in my workspace. The problem vanished, after I had deleted and re-created the filters. From then on I could not re-produce the problem.
I am relatively sure that it is not an iSphere problem. Last but not least there is no caching by iSphere.
Thomas.
I finally figured it out. Here are the steps to reproduce the problem:
1) Create a new IFS filter for log files only (*.log).
2) Create a new filter (same path as #1) for all files (*).
3) Restart RDi, e.g. File -> Restart
It is essential to create the Log Files Only filter first, followed by the All Files. I already reported the problem to IBM.
Hi Thomas,
Do you mean that the problem doesn't occur if I create the Log files only filter first?
Because I tested with a new workspace just now, create the All files filter first, then the Log files only filter, and I get the same problem.
Peter
Exactly. I did it again. First I created the "All Files" filter and then the "Log Files Only" one. After restarting RDi, the filters work as expected.
And to be sure for 100% I created a new workspace and started over. Same result.
Thomas,
the filters themselves works as expected, they show all files or only the log files.
However, if I right-click a subfolder in a filter and choose "iSphere Stream File Search", it will show all files in the folder even if I use the log files filter. But only if I run a search on the all files filter first.
Also I noticed that the search is only done for files in the folder itself, not in subfolders. Don't know if this is by design? I don't see a "include files in subfolders" checkbox.
Don't know how many filsters and workspaces I created, today. sigh.
Good to know that we are now at the core of the problem.
The problem is that I do not have any information about the filter if the user selected an item below the filter entry. In such cases Eclipse provides an IFSRemoteFile object, which has no knowledge about whatever filter it is related to. Therefore the only thing iSphere can do is get the path from the selected entry and start a search from there with no restrictions. By the way that is the reason for the additional "Stream file type" filter on the search dialog. Figure: debugger-folder-selected.png
That is missing in the help text.
In the other case of that a filter is selected for the iSphere search, Eclipse returns a SystemFilterReference object with all the information of the filter. Figure: debugger-filter-selected.png
IFS directories can grow fairly large and hence I restricted the depth to the current (selected) directory and its direct children (= one level down).
It is in the help:
"Note: For now iSphere stream file search is restricted to resolve subdirectoriesdown to 1 level, because IFS directory trees may be extremely large."
Of course I could add a switch for removing that restriction. But is that really a good idea? The amount of data returned could be very large. Another option would be to specify a maximum number of elements to read. Resolving the directory tree would take the same time (from the first to the very last element) but the number of elements returned could not exceed a given maximum.
I do not know. Maybe too many thoughts.
Thomas.
Last edit: Thomas Raddatz 2024-04-25
Hi Thomas,
is it my version of iSphere or does filtering on file type
*.logsimply clear the file list in which to search? Or is that in a newer (beta) version?The other remarks you make do sound very reasonable, especially the part about limiting the search to files in the folder itself, not in subfolders.
Hi Peter,
The problem that filtering for a type on the iSphere search dialog clears the list, is the bug that I mentioned above and that I fixed in iSphere 6.0.4, which I released a few minutes ago.
I agree, that it may be good to restrict the number of items returned to a reasonable default value that could be changed by the user. I assume we will see that in the next version.
Thomas.
Hey Thomas,
in that case i'll wait for the release of the next version.
Thanks for the quick solution!
Peter
That may take a while, because Summer is getting closer.
Thomas.
No problem, now that i'm aware of the workaround (never open the 'all files' filter before the 'log files only' filter), it can wait.
Thanks again!
You're welcome.