[jcifs] Has anybody else seen problems with file names that start with a dot?

[Marc Savereux]

Thank you for the updates on this issue.

   What I have done to avoid the problem is use the .list() method first to 
get the file names and then build the URL path from there to create an 
SmbFile object for the associated file returned from the .list() method.

   In the case of my program, the difference appears to be under 3% in extra 
time taken using .list() versus .listFiles() to process the target files, 
although I can see under other circumstances than my own at this time, where 
the difference in time could be significantly greater than 3% and the network 
traffic would also be reduced significantly as well, if .listFiles() was 
being used instead of .list().

   As long as the consequences of using the java.net.URL class with respect 
to file name handling are documented, then a programmer can code accordingly 
to avoid problems.

Marc Savereux
XARO I.T. Services Inc.

On Sun, 9 Nov 2003 19:19:26 -0500 (EST), Michael B Allen wrote
> > Reproduced.
> >
> > I think it has to do with SMB URL handling...
> 
> Actually this appears to be just poor parsing on the part of the
> java.net.URL class. Unfortunately I don't think we cannot write our own
> parser and support java.net.URL at the same time because of the way the
> protocol handlers work.
> 
> The below test program illustrates the problem:
> 
> $ cat HttpURL.java
> import java.net.*;
> 
> public class HttpURL {
> 
>         public static void main( String[] args ) throws Exception {
>                 URL u = new URL( new URL( args[0] ), args[1] );
>                 System.out.println( u );
>         }
> }
> 
> $ java HttpURL "http://server/apath/" "filename.txt"
> http://server/apath/filename.txt
> $ java HttpURL "http://server/apath/" ".filename.txt"
> http://server/apath/.filename.txt
> $ java HttpURL "http://server/apath/" ".a#filename.txt"
> http://server/apath/.a#filename.txt
> $ java HttpURL "http://server/apath/" ".#filename.txt"
> http://server/apath/#filename.txt           <-----OOPS
> $ java HttpURL "http://server/apath/" "..#filename.txt"
> http://server/#filename.txt                 <----WORSE
> $ java HttpURL "http://server/apath/" "...#filename.txt"
> http://server/apath/...#filename.txt
> 
> Currently I don't think I can take this problem further and can only
> recommend that you avoid this particular class of filenames.
> 
> Hopefully the java.net.URI class is better...
> 
> Mike
> 
> > On Thu, Nov 06, 2003 at 08:06:47PM -0500, Marc Savereux wrote:
> >> Hello Christopher,
> >>
> >>    Here's a program that will demonstrate the problem, however, I have
> >> to
> >> correct myself in that the symbol that follows the dot does matter, and
> >> in
> >> fact .profile works but .#AboutJShell.java will not, it will simply drop
> >> the
> >> dot in that case. The fonts onscreen, made it look like there was a
> >> space
> >> instead of the missing dot, but using a monospaced font confirmed
> >> otherwise.
> >>
> >>    Here's the output from the test program.
> >>
> >> URL      : smb://192.168.1.165/vol1/
> >> Username : SMBTEST
> >> Password : SMBTEST
> >> [smb://192.168.1.165/vol1/] is a directory...
> >> Listing the contents of directory using .list() method.
> >> .#AboutJShell.java
> >> .profile
> >> Icon
> >> IMAGES
> >> IMAGES.TMP
> >> JAVAUTIL
> >> Network Trash Folder
> >> pfaro
> >> SMBTEST
> >> TESTFILE.DIR
> >> ~DFSINFO.8-P
> >> Listing the contents of directory using .listFiles() method.
> >> smb://192.168.1.165/vol1/#AboutJShell.java
> >> smb://192.168.1.165/vol1/.profile
> 
> -- 
> 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.



--
Open WebMail Project (http://openwebmail.org)