[jcifs] .freeDiskSpace()

[Michael B. Allen]

On Thu, 7 Nov 2002 15:10:02 +0100
andrea.lanza at frameweb.it wrote:

> 
> OK, I found it !!
> 
> freeDiskSpace()  becomes getDiskFreeSpace(), I found it  reading the
> source for SmbFile class.

Chris  made  me  do  it ;-> Since it was introduced in 0.7 I didn't see any
reason to deprecate it. 

> But I have a new problem.
> All my old code does not work anymore, I get a
> java.net.MalformedURLException: unknown protocol: smb
> when I try to use
>   sourceFile = new SmbFile(new java.net.URL("smb://"));
> 
> or directly
>   sourceFile = new SmbFile("smb://");
> 
> I saw a previous post from  Mats.Svensson at astrazeneca.com having
> (nearly) the same problem.
> I am working with an IBM Websphere Application Server 3.5.6, and I try
> to put the jcifs.jar in the application's classpath, but it didn't
> work.

If  you  use the first form, this is a different problem. You are using
the java.net.URL  class  *before*  you  using  SmbFile.  The  way Java
protocol handlers  work  is that you have to register the protocol
handlers that are not built into the system. 

In jcifs.Config there's a static initializer that looks like this:

    static {
        ...
        sys = System.getProperties();
        synchronized( sys ) {
            String pkgs = sys.getProperty( "java.protocol.handler.pkgs");
            if( pkgs == null ) {
                pkgs = "jcifs";
            } else {
                pkgs += "|jcifs";
            }
            sys.put( "java.protocol.handler.pkgs", pkgs );

And in SmbFile we have:

    static {
        try {
            Class.forName( "jcifs.Config" );
        } catch( ClassNotFoundException cnfe ) {
            cnfe.printStackTrace();
        }

So the act of loading the SmbFile class should trigger the protocol handler
to  be  registered.  But  again, if you use java.net.URL *before* you touch
SmbFile. So just load the protocol handler yourself with: 

    Class.forName( "jcifs.Config" );
    sourceFile = new SmbFile(new java.net.URL("smb://"));

But  this is redundant because the first thing the SmbFile constructor does
is  create  a  java.net.URL  from the string parameter so you might as well
just do:

    sourceFile = new SmbFile("smb://");

and  this  *should* load the protocol handler for you. If it doesn't then I
don't  see  what  the problem could be. There must be something about class
loading  or  system  property  handling with servlet containers that I just
don't know about. 

Any servlet container gurus out there have any ideas?


> 
> No changes in my code were done (apart from changing isWorkgroup() and
> freeDiskSpace() methods with theirs new equivalent)
> 
> I am almost sure that the problem is the now pure native way of
> handling smb:// url, using java.net.URL
> 
...
> 
> Hi, I just downloaded (1 hour ago..) new jcifs_0.7.0b7 version.
> Previously I had jcifs_0.7.0b3 version.
> 
> I found that method isWorkgroup() does not exist anymore: no problem,
> it was deprecated
> ad I substituted that with a  (getType() == SmbFile.TYPE_WORKGROUP) 
> test.

Sorry,  I  had  to  get  rid  of  it rather than just deprecate it for some
reason. Can't remember. 

-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived.