[jcifs] jcifs-1.0.0 released / 5 Years and Beyond
Michael B Allen
mba2000 at ioplex.com
Mon Sep 6 19:08:52 GMT 2004
See http://jcifs.samba.org/ for an HTML version of this message.
According to the freshmeat page, JCIFS is 5 years old today. The project
has come a long way in those years. Its features now include:
* The NTLM HTTP Authentication Filter, which adds easy Single Sign On
(SSO) functionality to Java Servlet containers, is clearly the most
popular feature of JCIFS. Eric did a great job of deciphering the
details of that protocol. The filter is mind-numbingly easy to install
as all it requires is the JCIFS jar and a filter section in your
web.xml with two or three init parameters .
* The performance of JCIFS is one of its more surprising achievements.
Consider the client can enumerate 5GB of files and directories in less
than 10 seconds . To reduce memory usage and increase concurrency
JCIFS automatically reuses existing transports and sessions. One nice
artifact of this design is that the NTLM HTTP Authentication Filter
scales to thousands of active clients. And because the negotiated
credentials are cached in the user's HTTP session the number of
concurrent user's supported can be many times greater than that.
* The SmbFile.copyTo() method is a venerable feature in itself. All
file and directory attributes and timestamps are mirrored perfectly
. It employs an extra thread to write data while the next read
operation is in progress. This optimization makes JCIFS the fastest
client available for copying large trees of files and directories
across hosts (neither of which needs to be the local machine).
* Accessing DFS volumes (sub-trees of files and directories that
actually reside on another host) is fully transparent to the user. The
client may be redirected multiple times in the middle of any operation.
After a redirection has occurred the mapping is cached but the cache is
only queried for transports that indicate they host DFS volumes.
* SMB signing is robust and negotiated automatically with servers that
* The SmbRandomAccessFile implementation is a complete drop in
replacement for the standard java.io.RandomAccessFile. When opened with
SmbFile.FILE_NO_SHARE share access this class is a legitimate database
* Named Pipes of all types are fully supported. TransactNamedPipe,
CallNamedPipe, and standard file I/O style pipes are all supported
using a single generic API that conforms to the
* JCIFS' name resolution capability is very sophisticated. WINS, DNS,
NetBIOS broadcast queries, and remote lmhosts files are supported well.
Which services and the order in which each service is queried is fully
configurable. The name service cache policy is also adjustable.
* JCIFS implements the SMB URL Draft Specification V07 and processes
all SMB URLs through an SMB URL proticol handler. This same handler is
used to build standard java.net.URL objects which means once the
protocol handler is registered SMB URLs can be used with any
application that uses URLs (e.g.
Other features include NTLM and LMv2 Authentication , optimal request
batching, NT STATUS codes, full transactions, large file support, Unicode
support from the ground up , NTLM HTTP authentication wrappers for HTTP
and HTTPS clients, a simple logging facility, and extensive documentation.
If that's not enough, there's always jcifs-ext where bleeding edge JCIFS
But the best feature of JCIFS is the simplicity of the API itself. We have
diligently resisted "feature creep". The SMB URL allows addressing
resources with wonderful ease. The SmbFile class is a drop in replacement
for java.io.File so if you know how to use that, you know how to use JCIFS.
JCIFS is now one of the most sophisticated and powerful CIFS clients
available free or otherwise. It is used in production environments by many
large commercial organizations and the Open Source model has worked well
for us as these users have contibuted valuable feekback that has made JCIFS
To commemorate these achievements we are proud to release JCIFS 1.0. Aside
from fixing broken links and a few packaging tweaks it is not different
from 0.9.8 and we hope it stays that way. Moving forward, the 1.0 branch
will only receive critical fixes.
In recent weeks a MIDL compatible IDL compiler was developed. Coupled with
the Jarapac DCE/RPC framework for Java it is now practical to make MSRPC
calls. This means that the Microsoft network management API functions are
very close to being incorporated into JCIFS. IDL files need to be written
and APIs need to be devised but we will soon be able to create users, edit
groups, control NT services, reboot machines, edit the registry, execute
programs on a remote host, and much much more. This will open up an
entirely new level of integration between Java and Microsoft environments.
Finally, thanks goes out to Eric and Chris and everyone else that has
contributed their time. JCIFS is truely a great product because we have
taken full advantage of the Open Source model. We would not have made
nearly as much progress without the code, bug fixes, problem reports, and
solutions provided by our users.
 although running through web servers that also try to negotiate NTLM
HTTP or do not properly support keep-alives is problematic
 Client Host: 500MHz Debian Linux "testing" Java 1.4 JCIFS 1.0.0; Target
Workstation: 2.7GHz 5.77GB Windows NT 4 sp6; Nework: 100 Mbps full-duplex
switched; Test Program: examples/T2Crawler.java with println statements
commented out, default properties, ran 3 times to load up target
workstation cache; Results: $ time java -Djcifs.properties=../miallen.prp
T2Crawler smb://myworksta/c$/ 3 1000, real 0m9.929s user 0m5.580s sys
 although currently extended attributes are not copied
 NTLMv2 is not fully supported but LMv2 permits the client to operate in
 Unicode share names are not supported but will be soon now that RPCs
More information about the jcifs