From owner-freebsd-hackers Thu Nov 30 18:04:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA13027 for hackers-outgoing; Thu, 30 Nov 1995 18:04:35 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA13022 for ; Thu, 30 Nov 1995 18:04:24 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id SAA13348; Thu, 30 Nov 1995 18:03:39 -0800 From: Julian Elischer Message-Id: <199512010203.SAA13348@ref.tfs.com> Subject: Re: seekdir broken.. To: terry@lambert.org (Terry Lambert) Date: Thu, 30 Nov 1995 18:03:38 -3200 (PST) Cc: hackers@freebsd.org In-Reply-To: <199511301938.MAA01261@phaeton.artisoft.com> from "Terry Lambert" at Nov 30, 95 12:38:18 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3397 Sender: owner-hackers@freebsd.org Precedence: bulk Terry, look at what you just quoted.... > > Man page says: > ========================================================================== > > The seekdir() function sets the position of the next readdir() operation > on the directory stream. The new position reverts to the one associated > with the directory stream when the telldir() operation was performed. > Values returned by telldir() are good only for the lifetime of the DIR > pointer, dirp, from which they are derived. If the directory is closed > and then reopened, the telldir() value may be invalidated due to unde- > tected directory compaction. It is safe to use a previous telldir() val- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ue immediately after a call to opendir() and before any calls to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > readdir(). ^^^^^^^^^ > ========================================================================== This is exactly what is failing..... Note: the only way to "use a previous telldir value" is to do a seekdir(), so opendir(), readdir(), telldir(), closedir(), opendir, seekdir(), readdir() is, according to this, a valid (though dangerous if the dir changes) sequence. in FreeBSD this is not the case on everything else it IS the case.. who's right? > > 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) > > The telldir() return is a *token*. ok, but it's invariant in this case 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? > > 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.. > > > 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. > [...] julian +----------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / On assignment | / \ julian@ref.tfs.com +------>x USA \ in a very strange | ( OZ ) 300 lakeside Dr. oakland CA. \___ ___ | country ! +- X_.---._/ USA+(510) 645-3137(wk) \_/ \\ v