[jcifs] Life saver .... and ideas

[Allen, Michael B (RSCH)]

> -----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.

	Mike