Date: Thu, 30 Nov 1995 18:03:38 -3200 (PST) From: Julian Elischer <julian@ref.tfs.com> To: terry@lambert.org (Terry Lambert) Cc: hackers@freebsd.org Subject: Re: seekdir broken.. Message-ID: <199512010203.SAA13348@ref.tfs.com> In-Reply-To: <199511301938.MAA01261@phaeton.artisoft.com> from "Terry Lambert" at Nov 30, 95 12:38:18 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512010203.SAA13348>