Re: readdir/telldir/seekdir problem (i think)

On 4/25/15 5:52 AM, Jilles Tjoelker wrote:
> On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote:
>> Yes, this isn't at all safe.  There's no guarantee whatsoever that
>> the offset on the directory fd that isn't something returned by
>> getdirentries has any meaning.  In particular, the size of the
>> directory entry in a random filesystem might be a different size
>> than the structure returned by getdirentries (since it converts
>> things into a FS-independent format).
>> This might work for UFS by accident, but this is probably why ZFS
>> doesn't work.
>> However, this might be properly fixed by the thing that ino64 is
>> doing where each directory entry returned by getdirentries gives
>> you a seek offset that you _can_ directly seek to (as opposed to
>> seeking to the start of the block and then walking forward N
>> entries until you get an inter-block entry that is the same).
> The ino64 branch only reserves space for d_off and does not use it in
> any way. This is appropriate since actually using d_off is a major
> feature addition.
>
> A proper d_off would still be useful even if UFS's readdir keeps masking
> off the offset so a directory read always starts at the beginning of a
> 512-byte directory block, since this allows more distinct offset values
> than safely using getdirentries()'s *basep. With d_off, one outer loop
> must read at least one directory block to avoid spinning indefinitely,
> while using getdirentries()'s *basep requires reading the whole
> getdirentries() buffer.
>
> Some Linux filesystems go further and provide a unique d_off for each
> entry.
>
> Another idea would be to store the last d_ino instead of dd_loc into the
> struct ddloc. On seekdir(), this would seek to loc_seek as before and
> skip entries until that d_ino is found, or to the start of the buffer if
> not found (and possibly return some entries again that should not be
> returned, but Samba copes with that).

yes.. though maybe a hash of hte inode number and the name may be a 
better thing to search on..

I need to check on your statement about samba to see if its true for 3.6..


>