jcifs-1.1.7 from tgz

Sun Jan 16 17:30:17 EST 2005
jcifs-1.1.7 released

A  bug  introduced  in  a  recent  release that could cause threads to wait
indefinately  has  been  fixed.  After  time  many threads could be blocked
resulting  in  wasted  resources.  The  DC lookup code has been modified to
gracefully  handle  WINS  returning  an  empty  list (e.g. due to temporary
network failure). A simple fix has been applied that premits SMB signatures
to work without specifying preauthentication credentials. The getAttributes
method  will  now  return 31 bits of attributes whereas previously it would
mask  off the lower 6 bits that JCIFS actually makes use of. A bug has been
fixed  that under certain conditions prevented copyTo() from copying entire
shares.  A try/catch block has been added to copyTo() to permit the copy to
continue if an error occurs.

jcifs-1.1.6 from tgz

Mon Dec 27 17:53:42 EST 2004
jcifs-1.1.6 released

If  a variable length 8 bit encodings such as Big5 is used the NTCreateAndX
command    could    fail.    This    bug    has    been    fixed.   If   an
SmbFile{Input,Output}Stream  was closed, a subsequent operation could cause
the  file to be reopened. This behavior is now blocked such that operations
performed   on  a  stream  after  it  has  been  closed  will  generate  an
IOException.  Some  transport  layer  synchronization  has been adjusted. A
getPrincipal  method  has  been  added  to  SmbFile  that  will  return the
NtlmPasswordAuthentication  object  used  to  create  the file or pipe. The
documentation has been updated regarding transparent NTLM authentication in
Mozilla, the available method of SmbFileInputStream.

 jcifs-1.1.5 from tgz

Thu Dec 16 21:57:23 EST 2004
jcifs-1.1.5 released

It was discovered that an ArrayIndexOutOfBoundsException could occur if the
list  of domain controllers returned by NbtAddress.getAllByName was shorter
than  the  list  returned  in  the previous call (possibly because the WINS
query  timed  out  and switched to an alternate WINS server). All NTLM HTTP
Authentication Filter users should upgrade to prevent this error. Also, the
value  of  jcifs.netbios.cachePolicy  set  by the NTLM HTTP Filter if it is
not specified has been doubled to 20 minutes. Finally, some log levels have
been  increased  such that running with jcifs.util.loglevel = 3 temporarily
is  actually  reasonable in a production environment (must use loglevel > 3
to see individual SMB messages and loglevel > 5 to get hexdumps).

jcifs-1.1.4 from tgz

Tue Dec  7 18:34:35 EST 2004
jcifs-1.1.4 released

Two  bugs  regarding  the  upcasing of domain and username fields with LMv2
authentication   (used   with   lmCompatibility   =  3)  have  been  fixed.
Additionally  the  firstCalledName/nextCalledName  methods changed in 1.1.0
have been changed back to the old behavior. The change was not warranted as
it did not emulate Windows behavior.

jcifs-1.1.3 from tgz

Tue Nov 30 19:20:57 EST 2004
jcifs-1.1.3 released

A concurrency error was introduced with the getChallengeForDomain code used
by the NTLM HTTP Filter. This has been fixed.

jcifs-1.1.2 from tgz

Sun Oct 31 00:58:04 EDT 2004
jcifs-1.1.1 released

The  jcifs.smb.client.logonShare  (and  thus  the JCIFSACL NTLM HTTP Filter
example)  did  not  work. It would not restrict users to those found in the
ACL it would permit all authenticated users. This has been fixed.

A  bug  was  discovered  and  fixed  in  the named pipe code. If a specific
sequence  of reads were performed the pipe could become corrupted. This fix
is necessary for multi-pdu DCE requests to work.

A small bug in the new NbtAddress.getAllByName method has been repaired. It
will now broadcast for a name if a WINS address was not provided.

jcifs-1.1.1 from tgz

Thu Oct 21 19:20:04 EDT 2004
jcifs-1.1.1 released

A bug was discovered and fixed in the named pipe code. If a specific sequence of reads were performed the pipe could become corrupted. This fix is
necessary
for multi-pdu DCE requests to work.

A small bug in the new NbtAddress.getAllByName method has been repaired. It will now broadcast for a name if a WINS address was not provided.

jcifs-1.1.0 from tgz

jcifs-1.1.0 released

The behavior of the firstCalledName/nextCalledName methods has been changed
to try SMBSERVER* first, then the NetBIOS hostname, then the 0x20 name from
a Node Status. It is pretty universal now that SMBSERVER* rules the day and
most  servers  return  failure  with  the  NetBIOS  name  so  this behavior
eliminates a round trip during session establishment.

The  NbtAddress.getByName method has been implemented. This will return the
full  list of RDATA for a name query response. Currently I believe only the
0x1C  domain  lookup  actually  returns  multiple  results.  Note  this  is
different from getAllByAddress which does a node status.

The  socket code in SmbTransport has been modified to open the socket using
the transport thread. This permits the caller of the transport to call wait
for  RESPONSE_TIMEOUT.  This is great if your application has a tendency to
try  to connect to hosts that do not exist. Normally that would take over a
minute  to  timeout. The single threaded SmbCrawler actually performs quite
well with the right properties set.

An SmbSession.getChallengeForDomain() method has been added that returns an
NtlmChallenge  object containing the byte[] challenge and UniAddress of the
domain  controller  from  which  it came. This method will rotate through a
list  of  at  most  jcifs.netbios.lookupRespLimit  addresses  and will only
return  a  challenge  for a responsive server. Unresponsive servers will be
removed from the list until the jcifs.netbios.cachePolicy has expired. This
function  is  used  by  the  NTLM  HTTP  Filter  to  locate suitable domain
controllers.

Because  of  the above rotation there is a greater potential for transports
to  remain  open. Sessions with no activity (this is particularly true with
the  NTLM  HTTP  Filter which really only touches the session once when the
user is authenticated) will be logged off after jcifs.smb.client.soTimeout.

A  read  bug that only manafested itself with a certain EMC server has been
fixed.

jcifs-1.0.1 from tgz

Mon Sep  6 20:44:14 EDT 2004
jcifs-1.0.1 released

The  GUEST  account  fix  broke  guest  access  entirely  for machines that
deliberately  want  it.  So  this  is  the  original  fix but with the test
condition corrected.

jcifs-1.0.0 from tgz

Sun Sep  5 19:02:41 EDT 2004
jcifs-1.0.0 released

Other  than  minor  changes  in  packaging  this code is identical to 0.9.8
released  3 days ago. From now one all development will continue in the ???
branch so that the 1.x series remains as stable as possible.

jcifs-0.9.8 from tgz

Thu Sep  2 18:45:35 EDT 2004
jcifs-0.9.8 released

If  the  special  "GUEST"  account is not disabled (almost always is) it is
possible  for  a  bogus  username  to  be  authenticated successfully. This
problem was only partially fixed previously. A clause was incorrectly added
that  was  intended  to  allow  the  username  "guest"  to be authenticated
successfully.  It  is  now  not possible for "guest" to be authenticated at
all.

A  log  message  has  been  added to the NtlmHttpFilter that will be logged
whenever  an  SmbAuthException is triggered and the jcifs.util.log.loglevel
is  greater  than 1. For example, to enable logging authentication failures
with the filter add the following to the filter section in your web.xml.

    <init-param>
        <param-name>jcifs.util.loglevel</param-name>
        <param-value>2</param-value>
    </init-param>

An  ArrayIndexOutOfBoundsException  that  could occur if NTLMv2 is used but
lmCompatibility was not set to 3 accordingly has been fixed.

jcifs-0.9.7 from tgz

Tue Aug 10 21:25:03 EDT 2004
jcifs-0.9.7 released

It  was  decided that the NTLM HTTP Filter should not set Connection: close
headers,  a  new  SmbFile  constructor has been added and a rogue debugging
statement has been removed.

jcifs-0.9.6 from tgz

Thu Jul 22 23:06:47 EDT 2004
jcifs-0.9.6 released

A bug in copyTo() has been found that could result in the operation failing
and  timeing  out  if  the  negotiated  buffer  sizes  between  source  and
destination       servers       were       different.      The      default
jcifs.smb.client.snd_buf_size  has  been  changed  from 5000 to 16644. When
copying  data  between  servers  that  negotiate  larger  buffer sizes this
results in a noticable preformance increase.

Adjustments  have been made regarding a null pointer exception triggered in
releaseMid()  during certain error conditions. The releaseMid method should
not be passed null Mids.

Failover  to  the  jcifs.smb.client.domain DC for browser info if the local
master browser query fails.

Methods  have  been added to SmbSession.java that support the specification
of alternative port.

Fixed some debugging output.

Added clause to SmbFile.delete() to subvert exception "cannot find the file
specified"  exception  generated  because  Oracle FilesOnline version 9.0.4
doesn't send '.' and '..' like other servers.

Ammended  the  ntlm http doc to mention that the domain or domainController
property  is  required and that it will be suitable to authenticate clients
for  which  it  is  an  authority  as  well  as  domains  with which it has
established trust relationships.

jcifs-0.9.5 from tgz

Thu Jul  1 18:53:20 EDT 2004
jcifs-0.9.5

A  bug  introduced  in 0.9.3 could result in an infinite loop that exhausts
all  memory  in  the VM when enumerating workgroups and servers. This issue
has  been  fixed.  Also included is an updated to the NtlmHttpURLConnection
(now works with org.apache.xmlrpc.XmlRpcClient).

jcifs-0.9.4 from tgz

Mon Jun 28 13:29:39 EDT 2004
jcifs-0.9.3 released

The  specification  of a port in the SMB URL has been fixed. Full workgroup
and  server  enumeration  was  also  broken.  JCIFS  can  now enumerate ALL
workgroups  and  servers.  The  NtlmHttpURLConnection class for negotiating
NTLM with HTTP clients has been updated to be more robust and support POST.

jcifs-0.9.2 from tgz

Removed the HTTP redirect from the filter.

Tue Jun  1 23:23:08 EDT 2004
jcifs-0.9.1 released

If the "guest" account is enabled on a CIFS server it is possible for jCIFS
to  successfully  authenticate  even  with  an  invalid  username.  Windows
networks  virtually  always  disable  this account but apparently it is not
difficult to enable this condition when using Samba. NTLM HTTP Filter users
that  are  not  certain the "guest" account is disable should upgrade. This
release eliminates the possability of authenticating anyone without a valid
username.  Specifically,  a  small  clause  as  been  added  that throws an
SmbAuthException  if  the  server responds with the "is logged in as guest"
bit on.

Thu May 27 23:25:57 EDT 2004
jcifs-0.9.0 released

The  0.9 series is no longer beta. Aside from a very small code change this
release only includes documentation updates.

jcifs-0.9.0p6 from tgz

Sun May  2 22:57:30 EDT 2004

Started to add additional WINS entry support but still only the first entry is used.

Most SMB signature code has been moved into jcifs/smb/SigningDigest.java where it's state can more easily be tracked. This is more favorable for
dealing with issues such as failure during signature initialization or the scenario where NULL creds to IPC$ should not use signing after
LOGON_FAILURE with previous session setup.
The behavior of SmbNamedPipe.getOutputStream has changed. If PIPE_TYPE_TRANSACT and PIPE_TYPE_CALL are NOT specified a TRANS_WAIT_NAMED_PIPE will be
issued before the file is opened. This emulates a WaitNamedPipe follow by CreateFile client.
The return value of readWriteFormat is now checked against the NBT header length (from in.available()). If it does not match it is skip()'d and a log
message is written. This should allow jCIFS to get by the OS/400 bug in the Negotiate response.
The ssnLimit property will now cause new transports to be created to accomodate new sessions as opposed to the previous behavior of closing stale
sessions when the ssnLimit is reached. Values can be 0 meaning unlimited, 1 meaning strict 1:1 sessions:transports, and N for N sessions per
transport. A value of 1 should permit the NTLM HTTP Filter to operated with domain controllers that require SMB signatures. This functionality should
prove to be useful for a variety of other reasons as well.
Added additional checks to close NbtSocket in connect() in the event of an error. This should curb the CLOSE_WAIT sockets reported by Gary but
apparently this is not enough to completely eliminate them as traces show even an ACK'd FIN can still leave a socket in this state.
The SmbFiles resulting from listing a workgroup could result in those files have type TYPE_WORKGROUP when they should have been TYPE_SERVER.
Several bugs in the SMB signatures code have been fixed; 1) a concurrency flaw could result in the signing digest being updated inappropriately 2)
the signature of an errant session setup should be ignored 3) a padding byte was not properly considered that could sporatically result in
"Unverifiable signature" errors reading files (this is the outstanding mystery bug mentioned in the 0.7.19 release).
Fixed some incorrect path handling in the DFS referral code.
Two property defaults have been changed; jcifs.smb.client.listSize from 1200 to 65535 and jcifs.smb.client.listCount from 15 to 200. For high latency
networks I recommend changing the values back.
All access specifiers have been reviewed and changed to private or protected wherever possible and appropriate.
The NetBIOS socket OutputStream has been reduced to a virtually useless shell. The NetBIOS header is now handled within ServerMessageBlock.java.
Unfortunately it does not appear to have improved performance considerably. It's hard to tell from the testing performed.
The MpxControl inner class has been removed in favor of something much simpler. It no longer creates Integer objects with each transmission.
Unfortunately it does not appear to have improved performance either.

jcifs-0.8.3 from tgz

Mon Apr 19 20:23:10 EDT 2004
jcifs-0.8.3 released / File Corruption with HotSpot

A  serious  bug was discovered in the HotSpot VM on Linux that can cause an
offset  field to be encoded incorrectly resulting in file corruption. A bug
report  has  been  submitted  and the code in question has been modified to
avoid  the  problem.  If you are using the <tt>-server</tt> option on Linux
you  must  upgrade to this version of jCIFS. Big thanks to Richard Heap for
diagnosing and fixing this very elusive issue.

jcifs-0.8.2 from tgz

Sun Mar 14 18:54:14 EST 2004
jcifs-0.8.2 released

The DST adjustement used may not be correct. It has been commented out. The
problem regarding SmbFile.getParent has been fixed.

jcifs-0.8.1 from tgz

Thu Feb 26 19:26:14 EST 2004
jcifs-0.8.1 released

The  decision  to  exclude ATTR_HIDDEN files in generic list operations has
been  revoked.  All  list methods now include all files unless specifically
filtered.

The following bugs have been fixed:

  o Previously querying the last modified time or file size immediately
        following    a    SmbFileOutputStream.write   call   returned   old
        information.
  o The createNewFile method did not use the correct open mode.
  o The setLastModified method set the create time to an invalid value.

jcifs-0.8.0 from tgz

Tue Feb 10 23:44:45 EST 2004
jcifs-0.8.0 released

This completes the 0.8 beta cycle. There is no technical difference between
this release and 0.8.0b1.

Mon Nov 24 04:06:55 EST 2003
jcifs-0.8.0b1 released

Some  work  on  NetworkExplorer and DFS referrals has been performed but it
still  doesn't  work  right. Currently if a DFS referral is encountered the
DfsReferral  will  be  thrown into NetworkExplorer which then sends an HTTP
redirect. The problem is that when the SmbTransports close after being idle
for  jcifs.smb.client.soTimeout,  attempting to access servers with NPAs in
the  session  can cause a succession of authentication failures which on my
network equates to your account being locked (like mine is right now :)

An   artifact   of  this  work  is  that  NetworkExplorer  will  store  the
NtlmPasswordAuthentication  objects  in  the  HttpSession as npa-servername
where 'servername' is the name of the server that supplied the challenge.

And all of the fixes to the 0.7 series since 0.7.15 are included:

It  was  discovered  that  SmbComNTCreateAndX  as  well  as  SmbComReadAndx
commands  did not calculate MAC response signitures properly. In one case a
field  was  not  properly  decoded  and in the case of reading the payload,
which  is  read  directly  from  the  stream into the supplied buffer as an
optimization,  was  not  being  properly factored into the signature. These
issues have been fixed.

Only  SMBs  that  follow  authentication  need to be actually signed if SMB
signing  is  enabled.  Because  it  was  assumed  that  SMBs  would  follow
authentication  an  Exception was coded to be thrown if password hashes are
determined  to be inadiquate to generate a MAC signing key. However because
the  NTLM  HTTP  Filter  does  not send additional SMBs, signing will never
actually  occur. The Exception is only generated if the password hashes are
"externel"  (meaning  from  the NTLM HTTP Filter) but this is precisely the
case  where  signing  will  never  occur. Therefore, the Exception coded to
detect  external  password  hashes has been removed so that additional SMBs
will generate a signing error but the NTLM HTTP Filter will be permitted to
proceed without error.

The  NtlmPasswordAuthencation  class  has  also  been  made Serializable to
permit  certain containers to serialize the state of an HTTP session. It is
not  known  however  if the client will seamlessly re-authenticate when the
NPA  is  de-serialized and discovered to be invalid. Regardless, the Filter
will  now  work with these containers albeit possibly not to their greatest
potential.

JCIFS  will  now suppress the harmess "exception reading from socket input"
message  being  written  to  the log. Specifically when using the NTLM HTTP
Filter under load jCIFS would periodically write exceptions to the log like
the following:

Dec 19 10:45:14.474 - exception reading from socket input: IKOO635<1B>/172.81.13.154
java.net.SocketException: Connection reset
  at java.net.SocketInputStream.read(SocketInputStream.java:168)
  ...

This was occuring because the domain controller is periodically closing the
socket  to the server. This is harmless. JCIFS will automatically reconnect
and proceed as usual.

If  NT  SMBs are not negotiated jCIFS will now use SMB_COM_WRITE as opposed
to  SMB_COM_WRITE_ANDX. This was done to support NetWare 6 which apparently
does not implement this ANDX command.

jcifs-0.8.0b released

This  is  the  first  beta  release  of  the  0.8  series.  There have been
significant  additions  to  this  package. The most noteable is Distributed
FileSystem  (DFS)  support. This client fully supports DFS with deep paths,
multiple  redirects,  you  name  it.  This functionality required pervasive
changes so DFS users should proceed with caution and report any problems to
the  mailing list. Support for setting file attributes has been added as is
the long awaited RandomAccessFile.

o DFS  -  DFS  support  is  thorough.  All  DFS  operations  are completely
  transparent.  It  Just  Works.  The  client can be redirected an infinate
  number  of  times.  It  will reuse mappings established by other callers.
  Components of a path that do not fall within the DFS space and deep paths
  are  handled  properly. Also, note the new <tt>getDfsPath</tt> method can
  be  used  to  determine  if a file or directory falls within a DFS space.
  This  support  required pervasive changes so proceed with caution and run
  your  unit  tests  with  files  that  span DFS volumes. Please report any
  problems to the jCIFS mailing list.

o Random  Access  Files  -  The <tt>SmbRandomAccessFile</tt> class has been
  added.  All  features  of the analygous <tt>java.io.RandomAccessFile</tt>
  class  are supported and should function as a drop in replacement. Notice
  it   is   now   possible   to   set   the   size   of  a  file  with  the
  <tt>SmbRandomAccessFile.setLength()</tt> method.

o File    Filters    -    Support    for   <tt>SmbFilenameFilter</tt>   and
  <tt>SmbFileFilter</tt>  is  complete.  Because  CIFS  servers  can accept
  attributes  and a wildcard expression for filtering entries on the server
  side,  a  <tt>DosFileFilter</tt>  is  provided  that  will  accept  these
  parameters  and  pass  them to the server. The <tt>DosFileFilter</tt> can
  also  be  extended  to  create  highly  sophisticated  and efficient file
  filters.  Because of this work the <tt>list()</tt> and <tt>listFiles</tt>
  methods have been refactored and actually reduced in size.

o Complete copyTo - The <tt>SmbFile.copyTo</tt> operation will now copy all
  file  attributes  as  well  as  create  and last write times. Directories
  copied  using  this  method should be indistinquishable from the original
  minus  ACLs.  This  method  can now copy entire shares whereas previously
  only sud-directories could be specified.

o Setting Attributes and Times - It is now possible to set file attribites,
  the  create  time,  and  last  write  time  in a variety of ways. The new
  methods     are     <tt>setCreateTime</tt>,     <tt>setLastModified</tt>,
  <tt>getAttributes</tt>, <tt>setAttributes</tt>, <tt>setReadOnly</tt>, and
  <tt>setReadWrite</tt>.

o Complete   Delete   -   The  <tt>SmbFile.delete()</tt>  method  will  now
  completely  delete  directories  regardless  of wheather or not there are
  read-only files in them.

o The createNewFile Method - An <tt>SmbFile.createFile</tt> method has been
  added.

jcifs-0.7.19 from tgz

Mon Jan 19 22:06:54 EST 2004
jcifs-0.7.19 released

It  was  discovered  that  SmbComNTCreateAndX  as  well  as  SmbComReadAndx
commands  did not calculate MAC response signitures properly. In one case a
field  was  not  properly  decoded  and in the case of reading the payload,
which  is  read  directly  from  the  stream into the supplied buffer as an
optimization,  was  not  being  properly factored into the signature. These
issues have been fixed.

jcifs-0.7.17 from tgz

Tue Dec 23 03:43:15 EST 2003
jcifs-0.7.17 released

JCIFS  will  now suppress the harmess "exception reading from socket input"
message  being  written  to  the log. Specifically when using the NTLM HTTP
Filter under load jCIFS would periodically write exceptions to the log like
the following:

Dec 19 10:45:14.474 - exception reading from socket input: IKOO635<1B>/172.81.13.154
java.net.SocketException: Connection reset
  at java.net.SocketInputStream.read(SocketInputStream.java:168)
  ...

This was occuring because the domain controller is periodically closing the
socket  to the server. This is harmless. JCIFS will automatically reconnect
and proceed as usual.

jcifs-0.7.16 from tgz

Tue Dec  9 18:13:25 EST 2003
jcifs-0.7.16 released

If  NT  SMBs are not negotiated jCIFS will now use SMB_COM_WRITE as opposed
to  SMB_COM_WRITE_ANDX. This was done to support NetWare 6 which apparently
does not implement this ANDX command.

jcifs-0.7.15 from tgz

Thu Oct 23 01:18:29 EDT 2003

jcifs-0.7.15 released

The name service code has been modified to return a different response with
each  0x1C  domain controller query. The range of servers is limited to the
top  jcifs.netbios.lookupRespLimit  entries  in  the  NetBIOS response. The
effect  that this will have is that the NtlmHttpFilter and NtlmServlet will
rotate  through  domain  controllers when authenticating WWW clients. Also,
because  different  transports are used, fewer sessions will be multiplexed
over  each  resulting  in  an  increase  in scalability proportional to the
number  of  domain  controllers  used.  This  behavior can be turned off by
setting the jcifs.http.loadBalance property to false (the default is true).

The  jcifs.smb.client.ssnLimit  property  default value has been changed to
250 from 100.

Mon Oct  6 23:53:28 EDT 2003

jcifs-0.7.14 released

Eric's  LMv2  patch  has been merged. There is some uncertainty surrounding
the signing of SMBs if GUEST credentials are negotiated. On a related note;
the  "Concurrent  modification" issue has been resolved. The oversight with
this  one  was  that  it  was  believed  that only a thead calling into the
transport  should  ever  trigger  tryClose() which is not exactly true. The
transport  thread  can  call tryClose but prior to adding verify() calls it
was  rare  and  only  happend  when  the transport reached a state where no
further  operations  could  move  forward anyway. So rather than syncronize
tryClose,  I  have  changed  verify  to simply return a boolean value which
set's the new ServerMessageBlock.verifyFailed member. This is then examined
by  the  calling  thread  who will tryClose (with the transport locked) and
throw  the "Unverifyable signature" if verifyFailed. Finally there has been
a  straight  forward  but potentially dangerous change in SmbFile. All list
operations  now  build  a  list  of names or files using an ArrayList. This
assisted  in  fixing  another  problem  where NetServerEnum2 responses were
observed    to   return   server   names   of   0   length.   This   caused
ArrayIndexOutOfBounds exceptions. These entries are now ignored.

 jcifs-0.7.13 from tgz

Wed Sep 17 21:21:31 EDT 2003

SMB  signing  is  now  supported  and  there  have been some adjustments to
SmbFile.hashCode() and SmbFile.equals()

Mon Sep  1 19:18:52 EDT 2003

Added   code  to  logoff  1/10th  of  all  sessions  over  a  transport  if
jcifs.smb.client.ssnLimit is reached (fix for ERRSVR/90 errors).

jcifs-0.7.11 from tgz

Thu Jul 10 22:07:09 EDT 2003

Support  for  LMv2  authentication has been added. See the Overview page in
the  API  documentation  regarding  the jcifs.smb.lmCompatibility property.
Some  additonal  "cleanup"  has  also  been performed. One side-effect that
might be noticed is that the default domain/username/password can no longer
be  set  at runtime. Once the client is initialized the default credentials
are  fixed.  Setting  default  credentials are runtime was always an unsafe
operation. Create an NtlmPasswordAuthentication object instead.

Thu Jul  3 20:59:25 EDT 2003

There  have  been  two small bug fixes in the SMB layer; the count field in
the  SMB_COM_WRITE_ANDX  response  was  being ignored. Apparently the count
specified  in the request is always honored or we would have seen plenty of
file corruption by now. Second, the list() and listFiles() did not properly
handle  Transaction  buffering  with  certain  values  for the listSize and
listCount  properties  (if  multipart transaction responses are send). Also
removed  a  few  obnoxious warnings getting logged during file transfers if
Log.WARNINGS is set.

Regarding  NTLM  HTTP Authentication; there have been additions and updates
to  the  documentation  on the NTLM flags, a fix to NtlmSsp to only provide
the  target when requested by the client via the NTLM "request target" flag
(this   is   the   correct  behavior),  and  a  bugfix  to  NtlmSsp  to  do
Base64.encodeBytes(bytes,  false)  instead  of Base64.encodeBytes(bytes) (a
linewrap  in  the  header  can  cause  an  error).  Eric has also excellent
documentation detailing his analysis of the NTLM protocol:

  http://davenport.sourceforge.net/ntlm.html

Thu Jun 12 00:18:05 EDT 2003

It  was  discovered  that if a server responds to the NBT session setup but
not  to  the  SMB_COM_NEGOTIATE  request the client will hang indefinately.
This  is not a likely thing to occur because servers usually respond or not
at  all.  Regardless  it  has  been  fixed.  The  client will timeout after
jcifs.netbios.soTimeout in this situation.

Some tweeking of the NTLM http code has been performed.

Wed May 28 19:09:17 EDT 2003

jcifs-0.7.8 released

A bug in the new ntlm http client code was identified and fixed.

Tue May 27 21:40:58 EDT 2003

jcifs-0.7.7 released

A  deadlock  was  identified  in SmbTransport very similar to the one found
last  year.  A  significant  change  has  been made that greatly simplifies
synchronization in the transport layer. It eliminates this issue as well as
the  extra synchronization introduced to fix the previous problem. It is an
elemental change however so proceed with caution.

Two  new  packages  have  been  introduced.  The  jcifs.ntlmssp package now
contains  all NTLMSSP base code. This code is used by the NtlmHttpFilter as
well  has  the  new  NtlmHttpURLConnection class for transparently enabling
your  HTTP and HTTPS client to negotiate NTLM authentication. The other new
package  is  jcifs.https  which  just  contains  the HTTPS protocol handler
necesary for proper protocol handler registration. Please read the document
entitled  "Using  jCIFS  NTLM  Authentication  for  HTTP  Connections"  for
important details.

To permit SmbFileOutputStream to be used with unusual named pipe modes (see
5/1/03  message)  that  will  be  both  read  and written the open flags in
SmbFileOutputStream have been changed from O_WRONLY to O_RDWR.

The    attrExpiration    period    of    SmbFile    is    now    reset   in
SmbFileOutputStream.write()  to  prevent  jCIFS  from  reporting  incorrect
attributes  values  after  writing  the file. Previously it was possible to
write  to  the file and immediated check the timestamp or file size and get
an old value. This should no longer happen.

The  SmbFileInputStream.skip()  method  has  been implemented in a way that
will  not  result  in  any  IO to the server. Thus it is possible to resume
large downloads from the point of failure for instance.

Wed Apr 16 22:46:07 EDT 2003

jcifs-0.7.6 released

The  isDirectory method has been changed to return false if the target does
not  exist.  Previously  this  would return true which is inconsistent with
java.io.File.

Wed Apr  2 23:56:26 EST 2003

jcifs-0.7.5 released

More  refinement  to  the  NTLM  HTTP authentication code has been applied.
There  is  also  a fix for listing hosts from Windows ME/98/95 local master
browsers.

Wed Mar 26 19:17:24 EST 2003

jcifs-0.7.4 released

Some NtlmHttpFilter issues were reported by several users of Win98 clients.
Eric  has  provided  a  new  NtlmSsp.java  that  works correctly with these
clients.

Wed Feb 12 01:23:02 EST 2003

From    the    beginning   jCIFS   identified   SmbSessions   uniquely   by
domain\username. This meant that once a session was established it could be
shared  by  another  requestor even if they supplied an incorrect password.
This  was  done  for  reasons  that  strangely  enough  had  to do with SMB
chaining.  However  with  the  introduction  of  the http package it is now
common  to  use  jCIFS  to  authenticate  web  clients from a central jCIFS
instance.  This  introduces  a security flaw because there would be a brief
window  of  opportunity after a user logs in during which an impostor could
log  in  as that user with a simple change to their MSIE security settings.
This  problem has been fixed. Another related issue has also been fixed. If
the   NtlmHttpFilter  or  NetworkExplorer  servlet  is  supplied  with  bad
credentials  the  behavior  was to throw an SmbAuthException up through the
container.   Instead   these   classes   will  respond  with  the  standard
Authentication:   NTLM  response  triggering  the  password  dialog  to  be
displayed until correct credentials are displayed.

jcifs-0-7.3 from tgz

Wed Feb 12 01:23:02 EST 2003

A  security issue regarding the SmbSession.logon() method used by NTLM HTTP
Authentication  has  been fixed and a modification has been made to trigger
MSIE  to  redisplay  the  Network  Password dialog repeatedly until correct
credentials are supplied. The change was made in the core jcifs.smb package
however so test this in your dev environments.

Wed Feb  5 00:41:32 EST 2003

The   jcifs-0.7.0   and   0.7.1   releases   will   incorrectly   throw  an
ArrayIndexOutOfBounds  exception  if  a write of 1501 to 1504 is performed.
This release fixes that bug. You may also set jcifs.smb.client.snd_buf_size
=  1300  as  a  temporary work-around. It is also now possible to specify a
"ShareAccess"  with  SmbFileOutputStream  and  SmbFile  to  restrict  other
processes  from  accessing files jCIFS opens. Also, SmbFileOutputStream now
supports writing files larger than 4GB.

Wed Jan 15 22:34:14 EST 2003

jcifs-0.7.1 released

Three  bugs have been fixed regarding filenames with '#' signs in them, the
getInputStream(),   getLastModified(),  getDate(),  and  getContentLength()
methods  of  the  URLConnection  implementation, and isExists() incorrectly
returning false.

Thu Jan  9 00:06:23 EST 2003

jcifs-0.7.0 released

This  is  the  0.7.0  release  of  jCIFS, the Java SMB client. There is new
functionality  specifically  targeting  Web  applications  as  well as some
critical SMB URL fixes and feature improvements:

o The  new  jcifs.http package is very handy when building Web applications
  that need to integrate with MS corporate intranets. Adding a hyperlink to
  a  document  on  a  network drive is easy with Network Explorer (pictured
  right)  and  will transparently negotiate credentials with MSIE to browse
  SMB  resources  (really, no password dialog necessary). This package also
  boasts an NTLM HTTP Authentication servlet Filter for authenticating MSIE
  clients.  These are useful features because many of the tasks surrounding
  user  management  now  fall  back  to  computer support and HR. It is not
  necessary  to  add  and  remove users as they join and leave the company.
  Perhaps  most  important from the user's perspective; they do not need to
  enter  a username or password if their workstation is a member of an NTLM
  domain.  The  password  hashes  generated  when  they  logged on to their
  workstation  will be negotiated during the initial request for a session,
  passed through jCIFS, and validated against a PDC or BDC. This also makes
  the  user's domain, username, and password available for managing session
  information, profiles, preferences, etc.

o The  functionality used to authenticate and manage arbitrary creadentials
  has   been  exposed  in  the  SmbSession  and  NtlmPasswordAuthentication
  classes.  This permits NTLM password authentication to be integrated into
  applications without requiring Microsoft components or JNI.

o With  the  introduction  of the jcifs.encoding property the client is now
  truely  internationalized.  It  has been used successfully on OS/390 with
  native  EBCDIC  character  encoding.  See the Sun JRE documentation for a
  list of supported encodings.

o The  URL  issues  remaining  in  the 0.6 series have been fixed in 0.7 by
  converting  all SMB URL handling internally to use the java.net.URL class
  (Note:  directories  must  now  have  a  trailing  slash  and Java 1.3 is
  required).  Also  a  deadlock in the name service code was identified and
  fixed (repaired in 0.6.8 as well).

o A  copyTo() method has been added to SmbFile that is very fast at copying
  large directories across hosts.

o There  have  been  numerous  other  changes  including  the  mkdirs() and
  getType() methods, plain text password support (disabled by default), the
  available()  method and close() fix for Named Pipes, reading files larger
  than 4 GB, the NtlmAuthenticator class, and more.

All documentation has been completely reviewed and updated.

jcifs-0.6b from tgz

Fri Nov 16 04:07:05 EST 2001

jcifs-0.6b released

This is the first beta of 0.6.

jcifs-0.5.2 from tgz

jcifs-0.5.2 from tgz

 There have been significant changes under the hood. The primitives such as packet encoding/decoding and transport have proven very sturdy however
 the top level glue and logic driving the client really needed an overhaul in hindsight. The client is much smarter now whereas previously jCIFS
 was quite chatty and used some messages abusively (NodeStatusRequest). Some other cleanups that took into account allocation of buffers and large
 numbers of objects have resulted in measureable performance improvements. All of this should be transparent to the user however my confidence in
 the stabilty of 0.5.1 no longer applies. It will take some time to confirm everything works as advertised. I am confident however that any bugs
 will only require minor adjustments to fix. Of course the name resolution bug that triggered this crusade has been fixed.

 There are some API changes. Most methods of SmbFile throw the now public SmbException. Natrually, this will require changes to existing code. For
 example, if your code was:

 if( r.delete() ) {
   System.out.println( "delete successfull" );
 } else {
   System.out.println( "error!" );
 }

 you might replace this with:

 try {
   f.delete();
   System.out.println( "delete successfull" );
 } catch( SmbException se ) {
   System.out.println( "error: " + se.getMessage() );
 }

 There are quite a few different messages that can be provoked such as:

 The file is being used by another process
 The device is not ready
 All pipe instances are busy
 ...

 not all of which have text messages (and which ones do have messages are in only English at the moment). You can test and make dicisions based on the
 errorClass and errorCode of an SmbException. All SmbExceptions are thrown through these methods unless an object implementing the AuthHandler
 interface has been called with the static SmbFile.setAuthHanler method. If an AuthHandler has been specified the following authentication related
 SmbExceptions:

 Access denied
 Bad password
 The client does not have the necessary access rights for the requested function
 The user account has expired
 The user is not allowed to access this server from this client
 The user is not permitted to access the server at this time
 The password of the user has expired

 will not be thrown by SmbFile methods but rather passed in the AuthInfo object to the AuthHandler's authenticate() method along with the username,
 password,
 domain, and target URL if one of these SmbExceptions occurs. See http://lists.samba.org/pipermail/jcifs/2001-October/001553.html for a related
 discussion. I
 believe this is a powerfull feature in itself. This provides for sophisticated error handling and consistent error messages (the messages are the
 same as those reported by Windows clients). There is also an oppurunity to introduce a ResourceBundle of text messages here. I beleive it will work
 quite well and in practice I do not believe code will be cluttered with try/catch.

 The NbtAddress class was designed to handle NetBIOS name queries similarly to the common InetAddress class. Unfortunately a lapse in judgment
 integrated DNS
 queries into this class in jcifs-0.5 (thus the name service bug). The solution is to remove this DNS code and provide a wrapper class that handles
 both DNS queries as well as NetBIOS queries mainly delegating the work to InetAddress and NbtAddress. This class is UniAddress. Here is how each of
 these classes should be used:

 o InetAddress - Lookup a DNS name
 o NbtAddress - Lookup a NetBIOS name or perform NetBIOS specific
     queries (NodeStatus with getAllByAddress)
 o UniAddress - Don't know or care what type of name it is, try to
     find the name with both DNS and NetBIOS queries if necessary. Query
     behavior is governed by the jcifs.resolveOrder property.

 So generally the UniAddress class should be used if you wish to interface
 with name services directly (normally not necessary when working with
 the jcifs.smb package).

jcifs-0.5.1 from tgz

Mon Aug 27 00:29:02 EDT 2001

jcifs-0.5.1

Chris did some great testing at the CIFS Conference Interoperability
Lab and found three minor bugs. They are described in detail here:

http://lists.samba.org/pipermail/jcifs/2001-August/001428.html

These packages will now work with Java 1.1 as well as Java 2.

Sun Jul 29 04:01:18 EDT 2001

jcifs-0.5

This is the final release of the 0.5 series. It is the most stable and
complete product the jCIFS team has to offer. There are no known bugs. A bug
in the renameTo operation (would not always return false when it should have)
has been fixed, API documentation improvements have been made, and a
entry to the FAQ has been added.

Fri Jul 13 18:54:37 EDT 2001

jcifs-0.5b2

Thanks to Rob for realizing that attempting to read the same file from
different processes/threads yielded an "The file is being used by another
process" exception. We had the share flags and access masks wrong. A
Log.CRITICAL_EXCEPTIONS mask has been added for logging messages to the
console. If:

    Log.setMask( Log.CRITICAL_EXCEPTIONS );

is set, the "Access denied", "Bad password", and "The device is not
ready" sorts of exceptions will NOT be printed. The default is still
Log.EXCEPTIONS which encompasses both Log.CRITICAL_EXCEPTIONS and regular
Log.EXCEPTIONS so existing code will not be affected.

Thu Jun 28 21:04:15 EDT 2001

jcifs-0.5b

This is the beta release of jcifs-0.5. The 0.5 series has already been
through a stable release and there are no know bugs so we are confident
that it will perform well. New features since jcifs-0.4 include:

o SmbFile.list() Bug Fix - The jcifs-0.4 package had a serious bug that
  caused a TRANS2_FIND_FIRST2/NEXT2 endless loop. It has been properly
  fixed. This should be the first *complete* stable release.
o Share, Server, and Workroup Enumeration - jCIFS can now list the shares
  on a server, servers of a workgroup, and workgroups on a network.
o CallNamedPipe, TransactNamedPipe, and CreateFile Named Pipe API (Paul)
o Complete SMB Filesharing URL Scheme IETF Draft Support - The smb://
  URL scheme has been fully implemented. (Chris)
o Transactions and RAP API
o Transactions - Full multi-part Transaction requests(used by Transact
  Named Pipes)
o Daylight Savings Bug Fix - jCIFS was not properly correcting for
  daylight savings. (Urban)
o Full SmbComNTCreateAndX Support - We now look just like NT 4 instead
  of Winblows 95 :~)
o Unicode Alignment Bug Fix - Unicode alignment was generally not
  correct and caused many problems in early 0.5dev releases.
o SmbFile Method Behaviors - Fixed canRead() and re-thought and soul
  searched over the meaning of each of these methods and their behavior
  in the smb://, smb://name, and Named Pipe contexts. These methods
  should start to get pretty stable at this point.
o Clean, No Wait Exiting - Examples and other programs would wait 15
  seconds before exiting. This has been fixed by making the Transport
  thread setDaemon( true ). Same for the NameServiceClient Thread.
o Full Tuneable Batching
o NetBIOS Scope Fix
o New getServer, getShare, isWorkgroup Methods
o SmbShell and SmbCrawler Utilities

Thanks deserved for this release to Chris, Steve, Paul, The DJ, Urban,
James, Thierry, savaJe Technologies, and Josef.

FILES:

   jcifs-0.5b.tgz      jar and javadoc only for UNIX
   jcifs-0.5b.zip      jar and javadoc only for WINDOWS
   jcifs-0.5b.jar      jar file only

NOTE: The source code is included in the above packages. If
you would like to actually build jCIFS the ANT jar files are packaged
separately:

   ant.tgz             ant jar files
   ant.zip             ditto

Just unpack one of the above in the jcifs_0.5b directory, set JAVA_HOME in
build.{sh,bat} to bootstrap Ant, and run $ ./build.sh smb or > build smb.

IMPORTANT:

The jcifs.netbios.ns.nameserver has been changed to jcifs.netbios.wins
and the jcifs.util.Config class should now be referenced as
jcifs.Config. Programs written for jcifs-0.4 will not run without making
these two changes at least.

The jCIFS project uses the 'Ant' build tool available here:

    http://jakarta.apache.org/ant/

If you have *any* trouble please let us know on the mailing list by
sending mail to jcifs@samba.org or to myself at mballen@erols.com.

Enjoy,
Michael B. Allen <mballen@erols.com>

--8<--

                               JCIFS
           Common Internet File System Client in 100% Java
                      http://jcifs.samba.org

This is the JCIFS SMB client library written in Java. In short it
will enable Java applications to remotely access shared directories
on SMB file servers(i.e. a Microsoft Windows "share"). It is a fairly
religious implementation of the CIFS specification supporting Unicode,
batching, multiplexing, encrypted authentication, transactions, named
pipes, share/server/workgroup enumeration, and more. It is licensed
under LGPL which means commercial organizations can legitimately use it
with their propertietary code(you just can't modify the library itself
without reciprocation).

REQUIREMENTS:

Java 1.1 or above - http://java.sun.com/products/

INSTALLATION

Just add the jar file to you classpath as you would with any other
jar. More specifically:

UNIX:

1) Go to http://jcifs.samba.org and download jcifs-0.5b.tgz
2) Put it someplace reasonable and extract it with:

  $ gunzip jcifs-0.5b.tgz
  $ tar -xvf jcifs-0.5b.tar

3) Add the jar to your classpath. There are two ways to do this. One is to
explicitly set it on the command line when you run your application like:

  $ java -cp path/to/jcifs-0.4b.jar MyApplication

or perhaps export it in your .profile/.bash_profile like:

  CLASSPATH=$CLASSPATH:/home/miallen/path/to/jcifs-0.5b.jar
  export CLASSPATH

WINDOWS:

1) Go to http://jcifs.samba.org and download jcifs-0.5b.zip
2) Extract it with winzip and put the files someplace reasonable.
3) Add the jar to your classpath. There are two ways to do this. One is to
explicitly set it on the command line when you run your application like:

  C:\jcifs> java -cp jcifs-0.4b.jar MyApplication

The other way is to alter your system environment but I'm not confident
I can tell you accurately how to do that.

It is also common that the CLASSPATH be specified in a shell script or
batch file. See build.{sh,bat} as a hint.

RUNNING JCIFS:

In general the public API is extremely simple. The jcifs.smb.SmbFile,
jcifs.smb.SmbFileInputStream, and jcifs.smb.SmbFileOutputStream
classes are analogous to the java.io.File, java.io.FileInputStream,
and java.io.FileOutputStream classes so if you know how to use those it
should be quite obvious how to use JCIFS provided you set any necessary
properties(such as wins) and understand the smb:// URL syntax.

Here's an example to retrieve a file:

  import jcifs.smb.*;

  jcifs.Config.setProperty( "wins", "192.168.1.230" );
  SmbFileInputStream in = new SmbFileInputStream(
       "smb://username:password@host/c/My Documents/report.txt" );
  byte[] b = new byte[65535];
  int n;
  while(( n = in.read( b )) > 0 ) {
      System.out.write( b, 0, n );
  }

You can also write, rename, list contents of a directory, enumerate
shares, communicate with Win32 Named Pipe Servers, ...etc.

The protocol handler for java.net.URL is also in place which means you
retrieve files using the URL class as you would with other protocols. For
example:

  Class.forName( "jcifs.Config" ); //ensure protocol handler is loaded
  URL url = new URL( "smb://user:pass@host/share/dir/file.txt" );
  InputStream in = url.openStream();

This will also work with whatever else uses the URL class internally. For
example if you use RMI you can serve class files from an SMB share and
use the codebase property:

  -Djava.rmi.server.codebase=smb://mymachine/c/download/myapp.jar

To execute the Put example you might do:

$ java -cp examples:jcifs-0.4b.jar Put smb://usr:pass@host/share/file.zip
582K transfered

API documentation is included.

WHAT IS SMB AND CIFS?

Server Message Block (SMB) is an application layer networking protocol
for file and print sharing. It is the de-facto networking protocol for
Microsoft Windows platforms. The Common Internet File System (CIFS)
is the more generic name for all that encompasses the protocol and its
many layers. Collectively this is the networking protocol used when you
"Map Network Drive...", issue "net use * \\server\share" commands, use
smbclient on UNIX, smbfs on Linux, Sharity, OS2, server vendors such as
Network Appliance, EMC, and others.

WHY DO YOU NEED JCIFS?

This client is 100% Java and will work the same in a variety of
environments from Palm Pilots and applets to any UNIX that supports
Java. Naturally you can choose to run your applications on a platform
that supports mapping or mounting remote volumes into the local
filesystem but this assumes you know what shares you are accessing in
advance and what platform your application is running on(do you use
/mnt/pnt or H:\dir). Such an approach is not portable, unstable due to
unnecessary dependencies, and can be difficult to manage. JCIFS offers
Java applications that require access to SMB file services portability
and therefore the added stability that the UNIX environment can
provide. The JCIFS infrastructure is also highly extensible. If there
is a demand it will include a great deal of additional functionality
not available through a filesystem API such as printing, RPC, NT file
change notification, etc.

ACKNOWLEDGEMENTS

Special thanks to the Samba organization and Christopher R. Hertel for
starting the JCIFS project.