[jcifs] File naming problem

[Thomas Bley]

Hi,

Looks like you are using unicode characters in the share name.
I'm wondering why you see these names, but I think it can be an issue with the webdisk, I'll look at it.
See also Mike's mail from January.

bye
Thomas


This is what Mike has written about Japanese share names:

On Mon, 24 Jan 2005 02:30:36 -0800 (PST)
Praveen Kumar <stud_joker413 at yahoo.com <https://lists.samba.org/mailman/listinfo/jcifs>> wrote:

>/   I am trying to get a list of shares on my server.
/>/ It has one japanese share. SmbFile#listFiles() gives
/>/ me a SmbFile with name = null and path =
/>/ smb://server/?????/
/>/ 
/>/ I have tried setting jcifs.encoding and
/>/ jcifs.useUnicode properties but to no avail.
/>/ 
/>/ Are japanese shares supported in the latest JCIFS ?
/
Unicode share names are not supported at this time. That requires the
NetrShareEnumAll RPC which we have working but it will not be integrated
into jcifs for some time (2.0).

Mike



Alvin Anwar wrote:
>
> Dear Thomas,
>
> It's nice to hear from you so soon *I'm getting really desperate in 
> reading the codes of JCIFS*. Anyway, for example I have a shared 
> directory at
>
> \\192.168.0.67\ <file://%5C%5C192.168.0.67%5C>? ???? (not sure if u 
> can see this correctly)
>
> the link in Webdisk will be (cut from Webdisk -> view source)
>
> <a 
> href='/ba/base/192.168.0.67/%C3%90%C3%82%C2%BD%C2%A8%C3%8E%C3%84%C2%BC%C3%BE%C2%BC%C3%90/'>н¨Îļþ¼Ð</a>
>
> The link becomes broken and the folder is inaccessible from WebDisk. 
> However, in the second case, if the same folder is shared as
>
> \\192.168.0.67\sharedDocs\ 
> <file://%5C%5C192.168.0.67%5CsharedDocs%5C>? ???? (notice that I share 
> its parent folder in English name, instead of the Chinese folder itself)
>
> the link in Webdisk will be
>
> <a 
> href='/ba/base/192.168.0.67/sharedDocs/%E6%96%B0%E5%BB%BA%E6%96%87%E4%BB% 
> B6%E5%A4%B9/'>?????</a>
>
> *notice that the link value is different, even though it is the same 
> folder
>
> However, in the first scenario, if i access the folder using 
> /192.168.0.67/%E6%96%B0%E5%BB%BA%E6%96%87%E4%BB%B6%E5%A4%B9/, voila, I 
> can access my folder.
>
> I was wondering if this is more because of encoding issue (maybe some 
> part of the JCIFS handles in ASCII, UTF-8 or else). Thanks Thomas for 
> your reply, I'm looking forward for ur reply soon while I'm digging 
> myself to JCIFS code myself.
>
> Regards, Alvin
>
>     ------------------------------------------------------------------------
>     From: /Thomas Bley <thomas.bley at simple-groupware.de>/
>     To: /Alvin Anwar <alvin_anwar at msn.com>/
>     Subject: /Re: [jcifs] File naming problem/
>     Date: /Thu, 29 Dec 2005 05:12:49 +0100/
>     >Can you give me an example of a path that is not correctly retrieved
>     >and results everything in a broken link ?
>     >
>     >Thanks,
>     >Thomas
>     >
>     >Alvin Anwar wrote:
>     >>Hi all,
>     >>
>     >>Currently I noticed there's an inconsistency error in getting the
>     >>files' names for different level of shared directory. Let me
>     >>elaborate first. *Please correct me if I'm wrong somewhere, it
>     >>might be my mistake
>     >>after all*
>     >>
>     >>In JCIFS SmbFile getType() function, the shared directory is
>     >>specified as
>     >>\\ TYPE_SERVER \ TYPE_SHARE \ TYPE_FILESYSTEM \ TYPE_FILESYSTEM ...
>     >>
>     >>Currently I'm working on using JCIFS on file servers running
>     >>Windows XP
>     >>SP 2 Chinese version. The unstability was found when I tries to
>     >>list the files using listFiles() from SmbFile class at server level
>     >>(TYPE_SERVER).
>     >>
>     >>When I retrieve the name and display it in a webpage (using
>     >>IntergraTUM
>     >>WebDisk), some of the shared directory with Chinese characters are
>     >>retrieved wrongly (which makes everything a broken link). On the
>     >>other hand, when the shared directory (using Chinese character) is
>     >>located as
>     >>TYPE_SHARE or the next, it can be displayed correctly.
>     >>
>     >>Reading at the source code, I notice that listFiles() might be
>     >>calling
>     >>different functions, depending on the path of the inputted URL
>     >>(doNetEnum()
>     >>or doFindFirstNext()).
>     >>
>     >>Does anybody have faced this problem before? Or have I made any
>     >>mistake
>     >>somewhere?
>     >>
>     >>Regards,
>     >>Alvin Anwar
>     >>
>     >>
>     >>
>     >
>
>
> ------------------------------------------------------------------------
> Find love online with MSN Personals 
> <http://g.msn.com/8HMBENSG/2749??PS=47575>