Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
From: "Jared Graber" <jgraber@zedak.com>
To: "'Jakarta Commons Users List'" <commons-user@jakarta.apache.org>
Subject: RE: [vfs]sFTP Imaginary Directory Type (FOUND BUG)
Date: Tue, 28 Mar 2006 12:48:35 -0500
Message-ID: <034f01c6528f$d6141880$2629a8c0@ad.zedak.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <011601c649f9$20d397a0$2629a8c0@ad.zedak.com>
Thread-index: AcZJ+SCQPh5I3DMlSB+9bXRbrg4SFQIkzBDA

Well, I found the problem with the 2 libraries (VFS and JSch 0.1.25 which is
the latest) by adding logging to JSch (which to my surprise had NONE!) and
running multiple tests.

If in the middle of a file transfer the sftp server goes down, JSch chokes.
>From then on, a null pointer exception occurs in the stat method of the
ChannelSftp.  Unfortunately the method catches ANY exception and just throws
a new SftpException (or casts the exception if it was already a
SftpException) with no logging of what really happened.  

So the connection is busted, but the library isn't letting anyone know what
happened.

The SftpFileObject of VFS catches the exception (there is a TODO in there)
and sets the attributes of the file object to null.  This will cause the
type of the file to be imaginary.

Because the JSch library didn't handle the exception properly, this problem
will continue to occur until the program is restarted without putting in
safeguards.

Without changing VFS or JSch code, the solution I found was to get the
FileSystem object from the FileObject, cast it to an AbstractFileSystem (I
hate doing something like this) and calling the close() method on it.

If someone has a better solution (other than fixing JSch or making a change
to the SftpFileObject so that it closes the file system object when the
SftpException occurs), please let me know.

I'm a little confused on the reasoning behind the Imaginary File Type.  It
seems to me that it is just a catch all for anything that can go wrong.  If
that's the case, I would think an exception would make more sense.  It would
also give you an idea of what went wrong.

I hope none of the other supported file systems have the same type of
problem.

-Jared

-----Original Message-----
From: Jared Graber [mailto:jgraber@zedak.com] 
Sent: Friday, March 17, 2006 2:30 PM
To: Jakarta Commons Users List
Subject: [vfs]sFTP Imaginary Directory Type

Hi,

 
I've been using VFS (with the JSch library) to connect to an SFTP server.
Today we encountered an interesting problem that unfortunately I haven't
been able to duplicate yet.

 
One of our requirements is to get the name of all the files in a folder w/ a
specific extension.

 
This part of the app is part of a daemon thread and is called pretty often.

Here is the code:

 
                        FileSystemManager fileSystemManager = null;

                        FileObject directory = null;

                        TagFileListing tags;

                        try {

                                    fileSystemManager = VFS.getManager();

                                    directory =
fileSystemManager.resolveFile(this.getFileLocationURI());

                                    if (LOG.isDebugEnabled())
LOG.debug("File location: '" + this.getFileLocationURI() + "'");

                                    FileSelector tagFileSelector = new
FileExtensionSelector(".tag");

                                    if (LOG.isDebugEnabled())
LOG.debug("Directory Path: " + directory.getName().getPath());

                                    if (LOG.isDebugEnabled())
LOG.debug("Directory Type: " + directory.getType().getName());

 
                                    FileObject [] tagFiles =
directory.findFiles(tagFileSelector);

                                    tags = new TagFileListing();

                                    if (tagFiles != null) {

                                                if (LOG.isDebugEnabled())
LOG.debug("Tag files found:\t" + tagFiles.length);

                                                for (int i = 0; i <
tagFiles.length; i++) {

                                                            FileObject
tagFile = tagFiles[i];

                                                            String tagName =
tagFile.getName().getBaseName();

                                                            if
(LOG.isDebugEnabled()) LOG.debug("Found tag file: '" + tagName + "'");

 
tags.addTagFile(tagName);

                                                }

                                    }

                                    else {

                                                if (LOG.isDebugEnabled())
LOG.debug("No tag files found");

                                    }

                                    return tags;

                        } finally {

                                    if (directory != null)
directory.close();

                                    if (fileSystemManager != null)
fileSystemManager.getFilesCache().close();

                        }

 
I'm thinking that the problem is that the type for the FileObject directory
is FileType.Imaginary or I'm not using the provided caching correctly. 

No FileObjects are (incorrectly) returned by
directory.findFile(tagFileSelector)

 
If we restart the application, the type of 'directory' is FOLDER (which is
expected) and a correct set of FileObjects is returned by the findFiles
method.

The value of this.getFileLocationURI()  did not change when we restarted the
app (it originates from configuration parameters).

 
Any ideas as to what went wrong?

 
-Jared


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org