[jcifs] 0.8 objectives

Michael B Allen mba2000 at ioplex.com
Wed Sep 10 12:18:28 EST 2003

There are the current objectives for 0.8. A revised "todo" list also
follows. If it doesn't appear here and you want it please speak. Eric's
MAC signing and SmbFile.equals() tweaking are going into 0.7.13 to be
released eminently. Everything I say is subject to changes in wind


SmbFile Changes

Add createNewFile(). Very simple; just calls open( O_RDWR | O_EXCL ).
Signature is:

  public boolean createNewFile() throws SmbException

Add setLastModified(). This will probably require the
Trans2SetFileInformation transaction. Judging by the info levels available
for Trans2SetPathInformation it doesn't look like it's used much. My guess
is SMB_SET_FILE_BASIC_INFO 0x101 is probably what we want for both this
and setReadOnly but that largely depends on Windows95/98/ME.

  public boolean setLastModified(long time)

Add setReadOnly(). Hopefully just a different call to the above transaction.

  public boolean setReadOnly()

Add file and filename filters. Pretty strait forward. We should provide a
DOSFilenameFilter that doesn't really filter anything but just passes the
wildcard expression to underlying list operation.

  public String[] list(FilenameFilter filter) throws SmbException
  public File[] listFiles(FilenameFilter filter) throws SmbException
  public File[] listFiles(FileFilter filter) throws SmbException

Complete copyTo(). This method should copy extended attributes, truncate
overwriten existing files if necessary, and set modification times. It
should also be possible to copy an entire share. Ideally it should not be
possible to determine the difference between a source file and it's copy.
This will require implementing SMB_COM_WRITE because writing 0 at an index
with SMB_COM_WRITE is how you truncate a file in CIFS (like ftruncate).
Incedentally this is also needed to implement
RandomAccessFile.setLength(). I'm not yet sure how one reads and writes
extended attributes though...

Implement SmbRandomAccessFile. This is pretty strait forward. Note
setLength() is how jCIFS will permit the truncation of a file. I have a
plan for writeXxx() and readXxx() methods when I consolidate encoding
routines later so I will not provide those methods in this release0. Note
also, we cannot just extend java.io.RandomAccessFile. It has native and
final methods.

Implement DFS. From looking at a trace and reading the limited
documentation the way DFS works appears to be as follows. All pathname
based operations set bit 12 in flags2 indicating the client desires that
the server consider DFS when resolving pathnames. If a resource that falls
within a path that is not local, a STATUS_DFS_PATH_NOT_COVERED error (or
DOS equivalent) is returned. The client then issues a GET_DFS_REFERRAL
transaction to retrieve the name of the real server and path. Naturally,
the client should also consider this new path when conducting any future

This will require a hook in the transport layer that catches the
PATH_NOT_COVERED exception, performs the REFERRAL, adds the new path to a
map, build a new path, and reissues the request whatever it is. This is
all transparent to the client of course.  It will also be necessary to
move any affected path in the various SMBs into the ServerMessageBlock
superclass so that SmbTransport can operate on it transparently.



Write a simple Unit testing framework that can be used to exercise the
jCIFS API (and some of a server's capabilities).

Rewrite build.xml using Davenport's as a template.

Does the Delete on Close NT_CREATE_ANDX option work consistently across
servers? We could expose that function as the deleteOnExit() method but
we would need to keep the files transport open the whole time.

Change listFiles buffering strategy. Currently it reallocates the
array repeatedly. Surely there must be a more clever method. What does
ArrayList do?

Create ResourceBundle with internationalized error messages. See

Add a default workgroup for finding LMB/DMB in the absence of a master

Should URLConnection methods be improved?

Check Time/Date handling for shares in Hong Kong and Australia. I believe
they are in different timezones/daylight savings.

Remove PropertiesTree and replace with regular Properties.

Simplify jcifs.util.Log (greatly).

Remove NbtSocket. Encode and decode the NetBIOS header in the SmbTransport
layer. This will improve performance considerably. Particularly when

Port jCIFS to an embedded VM. This will require preventing jCIFS from
trying to use a Unicode encoding *completely*. Also it would be worthwhile
to profile memory and object usage a little more. JCIFS may be fast but
it can be faster still and it uses too much resources.

Reuse ServerMessageBlock objects more.

Can SmbFile implement XFile? Is XFile/XFileAccessor of any interest

Improve SmbShell. Better yet, create an SmbShell api for writing efficient
browsers that for example return file names as they are returned by
the server rather than storing them in memory and returning them all at
once. SmbShell would be quite nice if it actually transferred data and
had line editing, completion, etc.

Switch to NT status codes? Why?

DCE/RPC over SMB would permit Unicode in share names and share names
longer than 12 characters. NETLOGON is obviously useful. There are many
other compelling reasons to implement RPCs.

Alter canRead to try and open the file for reading and return false if
ERRbadshare is received? Err, as much as I hate to do this I think it
might be the right thing to do.

Correct for Unicode alignment in Trans2FindFirst2Response from NT with
useUnicode=no bug? This incongruence between MS servers and their support
for Unicode is the source of problems (e.g. the way short names are
returned in SMB_COM_TRANS2_FIND_FIRST2 responses from NT with Unicode
on/off. Is this still true?

Add an isLocked() method that simply tries to open the file with
FILE_NO_SHARE access and then close it immediately?

Write a CIFS server profiling/testing program or suite of programs that
can determine true capabilities of a server. Low priority and we don't
have enough functionality to really be useful yet and it's a BIG job.

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