okuyamak at dd.iij4u.or.jp
Tue Nov 7 01:54:31 GMT 2000
>>>>> "JA" == Jeremy Allison <jeremy at valinux.com> writes:
>> Run readdir() for 'An/' 'An/upperCase/' 'An/upperCase/file/'.
>> # Well, it might be better with getdents(2).
JA> This is *exactly* what the statcache does. After this cache
JA> is built, and a pathname comes in then a lookup is done to
JA> match the longest name in the cache, then the stat is done
JA> to ensure the mapping is still valid.
Think. What do you use that filename for?
If you are to open file, simply call open(), open() will check
validness for you anyway.
If you need status of that file(like getting filesize), calling
stat() for getting information is enough, you don't need extra
stat() call for validness checking.
The problem case is unlink(). But if you have both
'An/upperCase/file/paTH' and 'An/upperCase/file/pATH', you'll find
"AN/UPPERCASE/FILE/PATH" file even after you removed
'An/upperCase/file/paTH'. So, even if you re-check for validness,
we still have chance of falling into trouble.
So, it's useless to check for validness of path generated by
statcache. It is needed to re-check validness of each directory list
cache, if you're caching. But final result don't need validness
What we need is, what do you do in case you found invalidness on
operation ( like open(), unlink(), stat()... ) against statcache
information ( or when statcache failed in creating filename ).
Now we need to re-check directory informations.
>> #What do you do if you have both "An/upperCase/file/paTH" and
>> #"aN/UPPERcASE/FILE/PAth"? or "An/upperCase/file/pATH"?
>> # What is strategy for this treatment??
JA> You pick the first one that matches, what else can you do ?
Pick up the one with "most uppercased" filename, for example?
JA> Am I not being clear enough ? Is the code not clear here ?
Both your explain and code does not tell the reason why you need
stat() call. What you're explaining is "What's going on right before
stat()", but have nothing to do with "WHY CALL STAT(), when stat()
does not prove any validness anyway".
Kenichi Okuyama at Tokyo Research Lab. IBM-Japan, Co.
More information about the samba-technical