otros-systems / otrosvfsbrowser Goto Github PK

What steps will reproduce the problem?
1. Execute pl.otros.vfs.browser.JOtrosVfsBrowserDialog.main method.
2. Attempt to open a valid, local log file in OLV by specifying the absolute 
file path to the file in the Path: field of the file browser.

What is the expected output? What do you see instead?
Expect the file to be opened successfully.
Instead the file browser presents the file as if it were an empty directory, 
allowing you to choose the parent directory of the file.

What version of the product are you using? On what operating system?
0.2

Please provide any additional information below.
I gave the simplest test case above, but the same problem occurs for opening 
remote files with sftp.  I don't know about http.

Surely a file browser should know the difference between files and directories.

Copy and pasting file paths is a power-user tactic, and typing and keyboard 
shortcuts are preferred over mouse manipulations by many Gurus.  Not supporting 
file paths discourages power users from using this product.

What steps will reproduce the problem?
1. Use the file browser to open a directory with over two hundreds files.

What is the expected output? What do you see instead?
I expect to have some means to narrow down the items (files and subdirectories) 
I'm interested in.
My use-case at-hand is the BMC CMDB Logs directory.  It has hundreds of log 
files covering various CMDB subsystems, and I am only ever interested in one 
subsystem at a time.
Another use case is BMC ADDM.  There are many base log files present, and for 
most of them there are several for each "engine" multiplied by about 10 due to 
log file rotation and aging.
Instead I have no means to narrow down what is displayed.

Please use labels and text to provide additional information.
Add a simple text file labeled something like "Narrowing filter:".
The program would simply do a .getName().contains() test on the items, perhaps 
using a java.io.FilenameFilter or java.io.FileFilter.

I think that a general .contains filter like this is more generally useful and 
applicable than a more traditional filetype selector.  The filetype selector 
would not help for my use cases, where tons of files I want to exclude have the 
same suffix that I need.  If a filetype/filename-suffix selector is added, it 
must accept custom suffixes (like with a JComboBox or similar).

What steps will reproduce the problem?
1. Open browser 
2. click on file
3. Emplty list is shown

What steps will reproduce the problem?
1.Open a directory containing binary files with the browser
2.Select a binary file
3.The preview pane displays binary garbage

What is the expected output? What do you see instead?
Either nothing, or an indication that the file is a binary file.

Please use labels and text to provide additional information.
It's possible that it could be useful to view the text representation of the 
binary data, but I can't think of any time I would want to see it.

Could be accomplished safely by reading in the first 100 bytes or so and 
checking for any non-text characters where text-characters includes a character 
in any language plus spaces, tabs, line delimiters, perhaps page breaks.

Use case here is that I want to save (as favorite) not just a directory or 
single file, but a wild-card match of files.  In two applications that I use 
all the time, there are hundreds of files in the logging directories.  When I 
use OLV I always am interested in only a couple files matching a file glob 
pattern.  I can't save favorite literal filenames because these filenames 
change, but always match a specific glob pattern so that is what I want to 
favorite.

What steps will reproduce the problem?
1.Open a multi-file browser with sftp path ending with a glob pattern.
2.See attached screen shot.  The browser correctly shows the two candidate 
files that match the pattern.

What is the expected output? What do you see instead?
Since valid candidate files are displayed, I should be able to click on either 
file to preview or to open it.
Instead, clicking generates a preview stack trace in log, indicating that it 
thinks that the fileglob string is a directory and is appending the selected 
file basename to it:  "Could not read from 
"sftp://tideway@addm/usr/tideway/log/*patterns_*.log/tw_svc_eca_patterns_00.log"
 because it is a not a file.
Attempting to open the file causes a failure in 
JOtrosVfsBrowserDialog.getSelectedFiles.


Would be great if input (and saved) sftp and file URLs would work with glob 
wildcards in the last token.  Maybe this could be implemented easily by just 
checking for wildcard characters in the last segment of the path, and if there 
are then split off the last segment into a "Name filter".

What steps will reproduce the problem?
1. Execute pl.otros.vfs.browser.JOtrosVfsBrowserDialog.main method.
2. Use the refresh button to far right of the "Path:" line to try to get the 
browser to display something.
3. Try to get OLV to load a log file that resides in your home directory by 
keying in the full absolute path in the "Path:" field.
4. Key in the path to a subdirectory under your home.  This will open 
successfully. Then click the top "[..]" entry to get back to your home 
directory where the problem is back.

What is the expected output? What do you see instead?
When my home directory is listed in the "Path:" field up top, I expect to see a 
listing of my home directory.
Instead the listing is empty.

What version of the product are you using? On what operating system?
0.2
OpenSUSE Linux 12.3

Please provide any additional information below.
Steps 1 is all that is required to reproduce the problem.  Steps 2 t 4 are 
reasonable attempts at work-arounds that do not work.  #5 doesn't work as a 
work-around because of Issue 285.

There are 2 disastrous effects on end users here.  1: Impossible to open a file 
that resides in user home directory; 2: Impossible to use the file navigator to 
navigate to any subdirectory underneath their home directory without typing in 
a path (i.e., not "browsing").  For #2 the file browser is failing it's primary 
purpose of letting you graphically browse and navigate the filesystem, and #1 
is even worse.

What steps will reproduce the problem?
1. View a directory with the file browser.  Call this directory A.
2. Navigate up a directory.
3. Using an external file manager or console, touch a new file in directory A.
4. Navigate back down to directory A.

What is the expected output? What do you see instead?
When I navigate back to directory A, I expect to see an accurate representation 
of the directory when I "open" it again.
Instead I see a representation of the directory back when I opened it the first 
time.

Please use labels and text to provide additional information.
The refresh button is useful for efficiency and simplicity for when directory 
contents change when the viewer has that same directory displayed.
But it is unexpected and user-unfriendly to not refresh automatically when a 
directory is re-opened.  The browser implementation is fast enough that loads 
of directories with hundreds of files happens quickly.

What steps will reproduce the problem?
1. Launch main method of TestDialog or TestBrowser
2. Paste in the search bar an url like: http://localhost:18080/test/
3.

What is the expected output? What do you see instead?

I expect the list of the file in the folder. The same done on any browser works 
normally (an instance of Tomcat is running with listing enabled)
Instead I get the following exception:
INFO: Getting authenticator for http://localhost:18080/test/
java.lang.NullPointerException
    at pl.otros.vfs.browser.auth.UseCentralsFromSessionUserAuthenticator.requestAuthentication(UseCentralsFromSessionUserAuthenticator.java:70)
    at org.apache.commons.vfs2.util.UserAuthenticatorUtils.authenticate(UserAuthenticatorUtils.java:85)
    at org.apache.commons.vfs2.util.UserAuthenticatorUtils.authenticate(UserAuthenticatorUtils.java:68)
    at org.apache.commons.vfs2.provider.http.HttpFileProvider.doCreateFileSystem(HttpFileProvider.java:81)
    at org.apache.commons.vfs2.provider.AbstractOriginatingFileProvider.getFileSystem(AbstractOriginatingFileProvider.java:103)
    at org.apache.commons.vfs2.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:81)
    at org.apache.commons.vfs2.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:65)
    at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:693)
    at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:621)
    at pl.otros.vfs.browser.util.VFSUtils.resolveFileObject(VFSUtils.java:345)
    at pl.otros.vfs.browser.util.VFSUtils.resolveFileObject(VFSUtils.java:310)
    at pl.otros.vfs.browser.VfsBrowser$5.performLongOperation(VfsBrowser.java:277)
    at pl.otros.vfs.browser.actions.BaseNavigateAction$1.doInBackground(BaseNavigateAction.java:75)
    at pl.otros.vfs.browser.actions.BaseNavigateAction$1.doInBackground(BaseNavigateAction.java:1)
    at javax.swing.SwingWorker$1.call(SwingWorker.java:296)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at javax.swing.SwingWorker.run(SwingWorker.java:335)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

What version of the product are you using? On what operating system?
1.0.1 on Windows 7

Please provide any additional information below.

What steps will reproduce the problem?
1. Click on some previews.
2. Underlying library complains about unclosed zip streams.

What is the expected output? What do you see instead?
That the streams obtained are properly closed.

What version of the product are you using? On what operating system?
The newest sources.

Please provide any additional information below.
You should always close any input or output streams. Sure, when streams are 
garbage collected they are closed, but don't rely on this.

So at least in PreviewComponent 146:
          } finally {
              gzis.close();
          }
And in PreviewListener something like this:
        ByteArrayOutputStream outputStream = new ByteArrayOutputStream(previewLimit);
        InputStream inputStream = null;
        try {
          byte[] buff = new byte[512];
          int read;
          inputStream = fileObjectToPreview.getContent().getInputStream();
          int max = inputStream.available();
          max = max == 0 ? previewLimit : Math.min(max, previewLimit);
          while ((read = inputStream.read(buff)) > 0 && outputStream.size() < previewLimit) {
            if (isCancelled()) {
              return new PreviewStatus(State.CANCELLED, 0, max / 1024, KB, name, EMPTY_BYTE_ARRAY);
            }
            outputStream.write(buff, 0, read);
            publish(new PreviewStatus(State.LOADING, outputStream.size() / 1024, max / 1024, KB, name, outputStream.toByteArray()));
          }
        } catch (Exception e) {
          LOGGER.error("Exception when downloading preview", e);
          return new PreviewStatus(State.ERROR, outputStream.size() / 1024, outputStream.size() / 1024, KB, name, outputStream.toByteArray());
        } finally {
            if (inputStream != null)
                inputStream.close();
            outputStream.close();
        }
Note that java 7 makes this way more concise:
http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.htm
l

You might be interested in my app which uses the browser. Check it out at 
https://github.com/Stivo/DeScaBaTo
Screenshot of browser here:
https://07487052216888302625.googlegroups.com/attach/3deeb0bee914f6ce/browse.png
?part=4&view=1&vt=ANaJVrENJ2PPEgQT-xT_TcR_TycyUcLP2V4jeMJxEWXmUP1YK-Wtb3yTX2d8Sd
2Pd0lOYe5SM9J0vuqUNkc3H0LWmtAdSMkQFnUmfJeTR-5dLuC0-HaAJSo

Enhancement Request

What steps will reproduce the problem?
1.Run the file browser and open a directory containing .* and other hidden 
files 

What is the expected output? What do you see instead?
In the main table panel, I don't expect by default to have the listing 
cluttered up with items with names beginning with dot, or which are Windows 
hidden files (like Local* and App* subdirectories of Windows home directories).
Instead i see it all.

Please use labels and text to provide additional information.
I have never tried to distinguish Windows hidden files from Java, and that may 
not be possible, but hiding just the .* files and subdirectories would be a 
great improvement.
I suggest a "Show hidden" checkbox which is off by default, so that in the rare 
cases where somebody does want to see the hidden files, they can.

What steps will reproduce the problem?
1. Enter URL with wrong user/passowrd (sftp://user:[email protected]/
2. NullPointer is thrown.

What steps will reproduce the problem?
1. Type a bad filepath into the "Path:" field of the file browser and hit 
ENTER. (This is just one example).

What is the expected output? What do you see instead?
Since the filepath is bad, I expect some notification (end-user notification) 
about a problem having occurred.
Instead, the browser acts exactly as if the (bad) filepath is the path for a 
valid empty directory.  The path you typed remains in the Path: file and the 
status line says "Folder contains 0 elements".

Please use labels and text to provide additional information.
The error details are there, are reported by the logging system.  
Log-and-rethow, or an error-message-queue poller should be implemented so that 
the program doesn't go happily along presenting the user with wrong 
information.  Modal pop-up is traditional and probably best, but status line 
could be used to minimize UI contention issues.

What steps will reproduce the problem?
1. browse to a FTP server
2.
3.

What is the expected output? What do you see instead?
expected: list of files on FTP server
instead: no files listed (other than '.'), preview shows a directory listing

What version of the product are you using? On what operating system?
0.1, Windows 7, FTP server is SwiFTP on Android

Please provide any additional information below

Nov 04, 2013 10:34:36 PM pl.otros.vfs.browser.VfsBrowser goToUrl
INFO: Have 0 files in ftp://albert:***@192.168.1.36:2121/sdcard
Nov 04, 2013 10:34:36 PM pl.otros.vfs.browser.util.VFSUtils checkForSftpLinks
INFO: Checking SFTP links took 0 ms [NaNms/file]

I use Vfs in my own program to access the FTP server and it does not have any 
issues listing the files on the FTP Server.
.