[jcifs] Long share names and russian letters in filenames

Швец Андрей mactep at gorod.ru
Tue Jul 8 22:56:10 EST 2003


Thank you, Mike,
I've corrected the problem with Russian names. Forget it, because it was my
fault (:-/  The URLs that came to my servlet were formed incorrectly in the
trails.

Regards
Alex

-----Original Message-----
From: Allen, Michael B (RSCH) [mailto:Michael_B_Allen at ml.com]
Sent: Tuesday, July 08, 2003 3:00 AM
To: Швец Андрей; jcifs at lists.samba.org
Subject: RE: [jcifs] Long share names and russian letters in filenames




> -----Original Message-----
> From:	mactep at gorod.ru [SMTP:mactep at gorod.ru]
> Sent:	Monday, July 07, 2003 12:38 PM
> To:	jcifs at lists.samba.org
> Subject:	[jcifs] Long share names and russian letters in filenames
> 
> Hi, all jcifs developers!
>  
> I have the latest jcifs release 0.7.8, and recently I got stuck on 2 problems:
> - Number one is that all shares with names longer than 12 symbols are not visible! (I'm using the
> listFiles() method, didn't try list())
> 
	This is a known problem. It's one of only two real "problems" with jCIFS (that I can think of
	off the top of my head). We need to implement MSRPC to get Unicode share names larger
	than 12 characters. This will not be fixed soon. Incedentally the other problem is that URLs
	do not unescape hexadecimal escape sequences (e.g. somepath/with/a/russianchar%041Fin/it)
	but I believe it's possible to get around that.

> - Number two is rather more specific, but still:
> When I open an SmbFile with URL like "<some_path>/<last_name_in_russian>", it does open,
> but some operations like delete(), renameTo(), and maybe some other, are executed upon the
> "<some_path>/" file instead! So, when I tried to begin with URL like "<some_path>/<latin_letter>
> <the_rest_in_russian>" the operations were executed with "<some_path>/<latin_letter>". The
> <some_path> part may contain Russian letters, and it works correctly, but whenever those
> letters are encountered after the last slash, they are ignored.
> 
	It sounds like your server is negotiating Unicode but is not living up to it's obligations. I
	created a file on my NT 4.0 system in the Latin1 locale using the russian characters
	U+041F U+0440 U+0438 U+044E U+0442. You can see what these characters are here:

	http://www.unicode.org/charts/PDF/U0400.pdf

	I was able to run the following test program and took a packet capture of port 139 using
	Ethereal:

	import jcifs.smb.SmbFile;
	import jcifs.smb.SmbException;

	public class Delete {

	        public static void main( String argv[] ) throws Exception {
	                SmbFile f = new SmbFile( argv[0] );
	                SmbFile russian[] = f.listFiles();
	                russian[0].delete();
	        }
	}

	Everything looked correct to me. I suggest you try the same test and get a packet capture
	(you can send it to me directly). Also we will need to know the make and model of the
	server (e.g. Samba, W2K, Novell, etc).

	Mike




More information about the jcifs mailing list