-
Notifications
You must be signed in to change notification settings - Fork 30
qmail-local: close race window when creating file in tmp/ #119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
4658e0b to
1346071
Compare
1346071 to
ed26122
Compare
0373a78 to
956b31e
Compare
josuah
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The string handling for path creation and file descriptor are interleaved, and with the changes the order has moved, but reading multiple times, I cannot see any change of behavior.
956b31e to
098cc72
Compare
|
Would be nice to hear the opinion of @xenotrope and @schmonz given their work on #90. |
I read this code about six or seven times to see what it's doing. Classic qmail uses good, not great, uniqueness in picking Maildir filenames; The "stat(fntmptph,&st)" call loops 3 times (loops 0, 1, and 2) trying to pick a time-and-pid-combination filename that does not exist, then called open_excl on it, which is wrapper around "open(fn,O_WRONLY | O_EXCL | O_CREAT,0644)". O_EXCL will "Error if O_CREAT is set and file exists." In short, the open_excl() will fail and call "_exit(1)" if fntmptph exists, same as in the stat() loop. Removing the stat() doesn't save a syscall so much as it forces another fork() if the file already exists... ...but, this PR keeps the sleep(2) and moves the open_exl() into the loop, so I really can't see how this behavior is dramatically different. I haven't perf tested existing file failure reporting speeds between stat() and open(). That's the only real difference here with respect to catching and failing when fntmptph is already there. (Depending on the qmail server itself, you could possibly have multiple maildir_child() children spawning in the same directory within one second; PID recycling is not something that many OSes guarantee won't happen. Increasing Maildir uniqueness with other sources of randomness is a good way prevent this logic from ever needing to actually be useful.) |
|
The "saves one |
098cc72 to
63cfb62
Compare
|
I’m not smart enough to read this and be sure about it. Automated tests of some sort would be awesome here, if you’re up for it. |
f2a77d6 to
8049530
Compare
45555a9 to
af02dc0
Compare
The code checked if a file with the same name already exists and then tries to create it. It properly checks if the latter fails and retries later, but this is totally unnecessary: it could just try to create it, and handle it at this point if the file already exists. This also saves one stat() syscall per local delivery.
af02dc0 to
129357b
Compare
|
If you're still confident in this, let's merge it. |
The code checked if a file with the same name already exists and then tries to create it. It properly checks if the latter fails and retries later, but this is totally unnecessary: it could just try to create it, and handle it at this point if the file already exists. This also saves one stat() syscall per local delivery.
Depends on #113.