[jcifs] Life saver .... and ideas

Allen, Michael B (RSCH) Michael_B_Allen at ml.com
Wed Jul 16 10:05:02 EST 2003

> -----Original Message-----
> From:	rperrott at netcomuk.co.uk [SMTP:rperrott at netcomuk.co.uk]
> Sent:	Tuesday, July 15, 2003 3:41 AM
> To:	jcifs at lists.samba.org
> Subject:	[jcifs] Life saver .... and ideas
> Hi, just joined the list
> Cheers to those who wrote jcifs, it helped me out of a jam on a Win XP Pro PC with deliberately crippled WINS, I had a 
> directory cloning tool written in half a day, and no I didn't look at the examples, no time to browse loads of files.
	Beware jCIFS does not copy extended attributes, ACLs, and it cannot set file times
	(unless you're using copyTo() to Samba), or even trivial attributes. So I would not call
	such a program a "cloning" tool.

> Please could you consider the following:
> * adding terse example code fragments into the api docs, for the relevant classes, it takes too long looking through loads of 
> example programs when time is critical.
	I simply don't agree. I would prefer to look at very simple complete working examples
	that can be easily modified.

> * fix the api docs so that the various packages can be browsed like the Sun API docs.
	I think our arrangement is simpler. There are some public classes that users should not
	be concerned with. Just add a new build target for ant or run javadoc yourself.

> * add a jcifs.smb.SmbRandomAccessFile class to allow random access reading and writing.
	This requires an example Win32 program so that we can see what's happening on the
	wire. We have higher priority tasks at the moment.

> * have a branch of jcifs.smb or a jcifs.smb add-on which supports NIO e.g. Filechannel, ByteBuffer, MappedByteBuffer etc 
> for SMB, this would need to be integrated with a jcifs.smb.SmbRandomAccessFile class to enable access to a FileChannel 
> sub-class.
	You mean you want me to juggle *two* jCIFS? Uhg.

> BTW:
> I successfully wrote a FAT32 partition recovery program in Java (to recover all the directories and files in an 8GB partition 
> image), after I was shocked that none of the commercial tools could cope with a cluster size error!  You can have the 
> source if you like, but be warned it was not tidied up, uses NIO, MappedByteBuffer, FileChannel etc, so requires lots of 
> memory to run, however the use of FileChannels makes file export very fast too!
> Another Java project I'm just starting is a Windows Registry Hive file reader, so I can avoid the vagaries and security 
> restrictions of Win32 API interface.
	So you're just decoding the binary file? If (when) we do RPCs you could remotely edit the
	registry with jCIFS.


More information about the jcifs mailing list