| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 4288.1 | Does it work locally? | VMSNET::P_NUNEZ |  | Wed May 14 1997 09:16 | 7 | 
|  |     Marjan,
    
    Does it work for a long file name on a local hard drive?
    
    Could just be a DOS/COMMAND.COM limitation...
    
    Paul
 | 
| 4288.2 |  | GIDDAY::MITROVSKI |  | Wed May 14 1997 20:50 | 22 | 
|  | Paul,
If the file with a long name is stored on the local hard disk or in a NT share 
it works fine.It must be a combination of how PW stores a file with a long name
and how Windows 95 "for" command reads it.Here is a list of all combinations I
have tried and their results:
		Operating	Location of the		"FOR" loop can
		  system	 long filename		 read the file
		Windows 95	local hard disk		      YES
		Windows 95	PW VMS share    	       NO
		Windows 95	Windows NT share	      YES
		Windows NT	Any of the above	      YES
Regards,
Marjan
 | 
| 4288.3 | IPMT Time | VMSNET::P_NUNEZ |  | Thu May 15 1997 08:49 | 12 | 
|  |     
    I'm convinced ;o).  If you can, you might put the server in debug mode:
    
    edit pwrk$lanman:lanman.ini
    [vmsserver]
    debug=yes
    debugsize=99999
    
    and see if you can see why or, better yet, get an IRIS trace - but in
    either case, it looks like IPMT is appropriate...
    
    Paul
 | 
| 4288.4 |  | CPEEDY::wells.lkg.dec.com::wells | Phil Wells | Fri May 16 1997 11:48 | 10 | 
|  | The same command played from NT4.0 to PW5.0 does displays the lfns.
If w95's command.com's file searches ultimately results in smbsearch 
messages, smbsearch only support 8.3 names.  The client minimally 
needs to use t2find to find lfns.
If your trace show smbsearch SMBs then that is the problem and it is
a problem in the client.
Phil
 |