Date: Thu, 30 Nov 1995 19:44:14 -3100 (MST) From: Terry Lambert <terry@lambert.org> To: julian@ref.tfs.com (Julian Elischer) Cc: terry@lambert.org, hackers@FreeBSD.org Subject: Re: seekdir broken.. Message-ID: <199512010244.TAA00566@phaeton.artisoft.com> In-Reply-To: <199512010203.SAA13348@ref.tfs.com> from "Julian Elischer" at Nov 30, 95 06:03:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > It is bogus to open and close the directory and expect the token to > > live past the life of the open. > > In some ways I agree, exept that it is known to work on all other > systems and it seems to be commonly done > > > It is bogus to do the telldir() before the readdir() and expect a > > readdir() following a seekdir() to do anything other than return > > the current location. > > but is it bogus to do a seekdir() before the readdir() and > expect to get at least SOME effect? it appears that we have totally crippled > seekdir.. (why would it be of any use?) all I want it to do is skip past > the first two items in the dir I KNOW the token for the dir entry I want > is (3), > why can't I seekdir to (3)? it just ignores me.. and the next readdir() > returns "." (token 1) . telldir() however will return 4 assimng that > the read was for item 3 (which it wasn't) Well, the telldir returns the pointer to get to the *current* position, not the next postion. Seems to me the telldir() is at the wrong place in your sample code. It should *follow* the readdir(). A readdir() after the seekdir() will then return the *next* entry. The problem is that the getdirentries() is a snapshot of a single block. You are guaranteed (only because of the way UFS doesn't cross directory bounds when compressing in a directory block) only the atomicity of blocks, not the atomicity of offsets into blocks. > If you can't use seekdir, to get to a particular point in the directory > then what hte F*ck good is it? That's why it's called SEEKdir. > if SEEKdir doesn't SEEK then it's BROKEN, RIGHT? Well, you are calling telldir *before* you readdir(), then coming back in and doing a seekdir() to the place *it was at before your readdir()*, then doing a telldir(), and then doing a readdir(). Seems to me that the usage is broken. > > Assuming the directory has not changed, doing a telldir() *after* > > the readdir() would work on BSD. > > No, telldir after readdir() is quite valid.. it should return the address > of the NEXT TOKEN.. Then why are you doing it *before*? 8-). > > The real problem is that for WINE, it wants to have a search context > > that is a 32 bit value and a drive ID, but the "search context" for a > > UNIX system is the dir inode number (32 bits) the offset into the dir > > (32 bits) and the mounted device the inode is on (dev_t -- 32 bits). > > you've lost me, sorry, brain in low gear today. DOS can continue a search at any time. Like 30 days from now. Since entries are monotonically increasing in the absense of a free space, entries are never relocated. It is the relocation of entries that makes it impossible to continue the search. In the NetWare file system, once a block is used as a dirblock, it is *never* reused as a data block. Thus NetWare's 32 bit value is the directory entry address itself, on the given drive. Crossing mount points adds a dev_t to the context in UNIX. If each device was only exported once, then a drive letter would map to a single device and there wouldn't be a problem. UNIX has too much context overhead for a DOS search context to sufficiently identify the the next directory entry by its 32 bit value. WINE does what it does because it doesn't understand how to deal with the mapping correctly. Fix the way the mapping is dealt with in WINE and you fix the problem. Closing the directory isn't the way to do it. It seems they are trying to conserve file descriptors. If you used getdirentries, you could make up the required 32 bit ID, no problem. Look at how the SAMBA code creates a DOS search context in the server code in response to a DOS FindFirst from a client machine. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512010244.TAA00566>