If you perform this request on a directory with exactly 50 files
(plus '.' and '..' which brings the total to 52 objects), the first
reply for the SMB server completely satisfies the query (server
side is Windows 2000 Professional).
The smbfs client then performs a TRANS2_FIND_NEXT2 using the last
file name as the resume key. The response returns a SearchCount
of zero (ctx->f_ecnt == 0) and an EndOfSearch code of zero.
Any attempt to get more entries with calls to TRANS2_FIND_NEXT2
result in Badfid (bad file descriptor). I suspect the return of
SearchCount of zero means that end-of-search has been reached and
the Sid is now closed.
The solution is to set "SMB_RDD_EOF | SMB_RDD_NOCLOSE" after getting
back a zero SearchCount, I've tested this in the field on a quite
a few systems, aggressively accessing Windows shares over smbfs
and it appears flawless.
I was initially concerned about the possibility of resource exhaustion
on the Windows server. I was afraid by not officially closing the
search, it would leave a resource hung-up and over time, exhaust
some sort of "open search table" limit. I've since convinced myself
this is NOT the case.
Windows needs to be able to handle clients that come and go over
time. If the search is not closed, Windows will close it if it
finds it needs more resources. I've testing this on directory
searches descending into 10's of thousands of folders, with 100's
of thousands of files.
it was initialised quite late due to its reliance on disc data the mount
process could have stopped before initialising and thus could panic again
only now for uninitialising an not initialised pool! *sigh*
the same memory block allocated as before and it bombs out on its
descriptor pool allready being initialised. It turns out that the pool was
not allways destroyed. This fix ought to clean it up whatever the cause of
the mishap that results in a reject.
253 of the superblock be zero. Searching the net failed to find any
justification for checking these bytes; all available references say
that they are part of the boot code and not BOOTSIG2 and BOOTSIG3.
Modify the MSDOS 7.1 bootsector definition to have 420 bytes of boot
code and no BOOTSIG[23], rather than 418 bytes of boot code, to follow
available references and apparent Windows practice. A test build
showed that these defines are not used other than in the check removed
by this commit.
Patch tested on netbsd-3, and enabled mounting of a 4 GB CF formatted
under Windows XP and then in a digital camera. The CF was previously
unmountable.
Concept approved on tech-kern by christos@ and martin@.
While touching all vptofh/fhtovp functions, get rid of VFS_MAXFIDSIZ,
version the getfh(2) syscall and explicitly pass the size available in
the filehandle from userland.
Discussed on tech-kern, with lots of help from yamt (thanks!).
allocated space was 2048 bytes, but when adding 1024 to the variable
`unix_name' to split the allocated space in half it effectively starts just
OUTSIDE the allocated space. This ought to fix memory corruption bugs when
using UDF.
This is a routine to revisit one day.
- struct timeval time is gone
time.tv_sec -> time_second
- struct timeval mono_time is gone
mono_time.tv_sec -> time_uptime
- access to time via
{get,}{micro,nano,bin}time()
get* versions are fast but less precise
- support NTP nanokernel implementation (NTP API 4)
- further reading:
Timecounter Paper: http://phk.freebsd.dk/pubs/timecounter.pdf
NTP Nanokernel: http://www.eecis.udel.edu/~mills/ntp/html/kern.html
