okuyamak at dd.iij4u.or.jp
Tue Nov 7 05:33:12 GMT 2000
>>>>> "JA" == Jeremy Allison <jeremy at valinux.com> writes:
>> If you are to open file, simply call open(), open() will check
>> validness for you anyway.
JA> For the open case only, this is true. But remember, we need to
JA> know if this open did the create or not (for the SMB flag returns).
For some exceptional cases, like EXCLUSIVE CREATION, you simply need
to call open with ( O_CREAT | O_EXCL ), so I don't think those will
be of any matter.
For other(usual) cases, if you really did find filename in statcache:
1) Use open() without O_CREAT option. If return was >=0, then the
file does exist, with file descriptor in your hand, and you know
that you didn't create file.
2) Then call open() with O_CREAT option. Since of 1, we know that
the file is being created. This sureness is at least as good as
the case you use stat(). Yes, there is exception.
Always check for ENOMEM, EMFILE, ENFILE, for those are the
The above gives you lot more robust, and cheeper way of calling.
Because, at step 1, you'll get file descriptor with "SURE" that file
already exists. At step 2, you'll get result as sure as, original.
These means it's more robust.
If you could open file at step 1, stat() call is fully reduced.
If you could open file at step 2, open() overhead at step 1 is
exactly the same as case you used stat(), for this overhead is
really "LOOKING FOR A FILE" overhead, which will turn out to fail
for both stat() and open().
Because of the same reason, smbd_mktemp() is also useless.
You should create smbd_mkstemp() instead, calling open() instead of
stat() to make sure it does hold the file descriptor with exclusive.
# overhead does exist when you're making shared working file,
# for you have to close file, then re-open it with same name again.
# But this overhead is not very large. close() does not require
# any search. On other hand, if you simply mktemp() the filename,
# someone might use it while you're passing it to someone.
>> 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.
JA> Yes - hurrah ! You have got to the point I did when I re-wrote
JA> the code in Miami :-).
Then, this was fixed. I used to see stat() call being requested
for same file twice, contiguously, on 2.0.7.
JA> For any call that does information retrieval, the stat() call in
JA> the statcache returns the SMB_STAT_STRUCT into the main SMB
JA> processing function, and then uses it.
Even with SMB*Create*?
Kenichi Okuyama at Tokyo Research Lab. IBM-Japan, Co.
More information about the samba-technical