Hide Forgot
(In reply to comment #0) > when atime/mtime that is to be set is sent along with truncate, shouldn't we do > the truncate operation first? In the code truncate is done in the end which > negates the effect of setting of atime and mtime. How can be such a thing triggered? Is there an operation on the filesystem which implies sending a SETATTR with *time + truncate at the same time? Or is it a theoretical problem?
(In reply to comment #1) > (In reply to comment #0) > > when atime/mtime that is to be set is sent along with truncate, shouldn't we do > > the truncate operation first? In the code truncate is done in the end which > > negates the effect of setting of atime and mtime. > > How can be such a thing triggered? Is there an operation on the filesystem > which implies sending a SETATTR with *time + truncate at the same time? Or is > it a theoretical problem? I do not know if it can be triggered, just theoritical. Under what circumstances can truncate be tugged along with other SETATTR calls? What is the primary reason for the kernel to combine the calls? just optimization?
(In reply to comment #2) > I do not know if it can be triggered, just theoritical. > > Under what circumstances can truncate be tugged along with other SETATTR calls? > What is the primary reason for the kernel to combine the calls? just > optimization? I think so. What I can recall now, truncate, utime, chmod, chown (and variants) are the syscalls which imply setattr fop being invoked, and each of these modifies only one kind of attribute.
when atime/mtime that is to be set is sent along with truncate, shouldn't we do the truncate operation first? In the code truncate is done in the end which negates the effect of setting of atime and mtime.
As per standard (posix), only when setuid/setgid is set on a file, and you do truncate(), then chmod is triggered together with truncate(), not utimes(). Marking invalid.