Le 6 juil. 09 à 23:07, Ralf Becker a écrit :
Hello Axel,
[...]
It's not just the log message. If you have a look on the entire function, you'll see that it fails if fchown fails:
[...]
Yes, you're right; I've been too elliptic... :-(
I was worried with a "solution" that potentially could fully hide
deeper problems, hence the suggestion to at least leave something in
the logs.
While this function seems to create all dotlock files (not just for the .subscribtions file) this means that on same NFS(4) file systems dotlocking is actually not working.
After a quick look, it seems that dotlocking for mbox mailboxes goes
through another path, and skips that fchmod() operation.
But please don't ask why. ;-)
The linux man page of chown(3) (in place of fchown(3)) says:
-----------------------------8<-------------------------------- If owner or group is specified as ( uid_t)-1 or ( gid_t)-1, respectively, the corresponding ID of the file shall not be changed. If both owner and group are -1, the times need not be updated. Upon successful completion, chown() shall mark for update the st_ctime field of the file. ------------------->8------------------------------------------
Is my understanding of these sentences correct? "If owner and group are -1, nothing is done?"
In this case it should be save to skip the call, shouldn't it?
Yes, I guess so.
Unless the rationale for that call is to ensure a correct cache
flushing for NFS clients, while being some kind of (costly) no-op
otherwise?
Ahem... Timo?
Axel