. and .. on search results

. and .. on search results

[Steve French]

There are cases in which servers fails to return . and .. in search 
(readdir) results over CIFS.   In particular Windows servers which 
export the root of a drive.

Is returning . and .. in readdir results always required (ie a client 
change is necessary to insert them if they were not returned)? and do . 
and .. have to be first in the list of entries in the directory (which 
would be very inconvenient since I may have to read through all of the 
directory search results)?  Although . and .. are usually returned in 
the first of what could be many search (Transact2 FindNext) responses 
from the server, I don't think it is required.

Re: . and .. on search results

[Jörn Engel]

On Mon, 10 April 2006 15:11:16 -0500, Steve French wrote:
> 
> There are cases in which servers fails to return . and .. in search 
> (readdir) results over CIFS.   In particular Windows servers which 
> export the root of a drive.
> 
> Is returning . and .. in readdir results always required (ie a client 
> change is necessary to insert them if they were not returned)? and do . 
> and .. have to be first in the list of entries in the directory (which 
> would be very inconvenient since I may have to read through all of the 
> directory search results)?  Although . and .. are usually returned in 
> the first of what could be many search (Transact2 FindNext) responses 
> from the server, I don't think it is required.

Iirc, this is not really defined.  No spec requires you to return .
and .. at all.  On the other hand, many userspace programs are plain
buggy if you don't.  So most filesystems try to return those two and
return them as the first results - even if they are not stored in the
on-medium format at all.  Jffs2 comes to mind as just one example.

Would it be hard to 
1) always prepend the actual results with . and .. and
2) remove . and .. from actual results, if they occur later?

Jörn

-- 
Schrödinger's cat is <BLINK>not</BLINK> dead.
-- Illiad
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: . and .. on search results

[Jan Harkes]

On Tue, Apr 11, 2006 at 11:12:15AM +0200, Jörn Engel wrote:
> Would it be hard to 
> 1) always prepend the actual results with . and .. and
> 2) remove . and .. from actual results, if they occur later?

Not hard, Coda does exactly that because it provides no guarantee that
the first 2 returned directory entries are '.' and '..' and some
application really didn't like that. (fs/coda/dir.c coda_venus_readdir())

Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html