[jcifs] .freeDiskSpace()

Michael B. Allen miallen at eskimo.com
Fri Nov 8 06:41:59 EST 2002

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 ) {

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. 

More information about the jcifs mailing list