[jcifs] Calling length on open file chokes

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Rob Wygand [SMTP:rob at wygand.com]
> 
> I just reread your message. Hmpf. Maybe I can look into getting you 
> Trans2FindFirst2/Next2 implementations. I'll need to see if we can fit 
> that in. Don't hold your breath! =)
> 
	Trans2FindFirst2/Next2 is implemented. These are the pair of SMBs to iterate over files
	used to list(). There are two ways to retrieve attributes of a file. One is with
	Trans2QueryPathInformation or SmbComQueryInformation and the other by iterating
	over all the files in a directory that meet the wild card criteria (usually '*') with
	Trans2FindFirst2 and Trans2FindNext2 and extract the attributes returned in the
	operation. Since list() only returns the filenames I did not bother to extract the attributes.
	Network Neighborhood and smbclient are inherently browser like so they use the
	Trans2FindFirst2/Next2 a lot. What you're seeing from those clients is probably coming
	from Trans2FindFirst2/Next2 responses. Silly that you can do this but if you query
	pagefile.sys directly you get an error but that's CIFS for ya. The *real* solution here is to
	implement listFiles(). This would return SmbFile[] rather than String[] which will already
	have the data populated. This isn't a lot of work however it demands some thought about
	implications on other things (do the files returned from listFiles() differ in any way from
	creating them with new?). But I think I might just have to give in and do it because we've
	bumped into this problem quite a bit recently. The listFiles() is faaar more efficient for
	browser like apps (like yours).

	Mike


> Allen, Michael B (RSCH) wrote:
> 
> > Mmm. I thought this would go away with the shareAccess change in SmbComNTCreateAndX.
	> Unfourtunately this particular file is opened by the Win32 Kernel which I guess uses a very restrictive