So, now for something completely different: I'm going to dig (pun not intended) into the #BIND9 source to try and determine why an incoming XFR doesn't alter the file's modification time.

[jpmens@mastodon.social]

So, now for something completely different: I'm going to dig (pun not intended) into the #BIND9 source to try and determine why an incoming XFR doesn't alter the file's modification time.

I noticed with `ls -l`, and somebody suggested stat(1).

The actual file contains correct SOA serial and altered RR, so the file has actually been written.

I don't think I've ever noticed that the file's mtime doesn't change.

[gjherbiet@mamot.fr]

@jpmens Just guessing here but as the file actually has a Bind DB format, perhaps it’s handler remains open (as long as #Bind9 is running) and is just written to.
What happens when Bind is stopped/restarted?
Certainly @ondrej or anyone at @iscdotorg can most confidently reply.

[ondrej@mastodon.rfc1925.org]

@gjherbiet @jpmens @iscdotorg 1. create tmpfile
2. write to tmpfile
3. swap the tmpfile with origfile
4. ctime/btime changes, atime/mtime stays
5. profit

[jpmens@mastodon.social]

@ondrej @gjherbiet @iscdotorg yeah, that’s what I thought, but I can’t profit. (top of shot shows `stat orig`)

This is ext4 FS on debian13. Also I cannot confirm originally shown behavior with new’ish BIND either on macOS nor on debian13.

[jpmens@mastodon.social]

@ondrej @gjherbiet @iscdotorg hmm, the echo(1) is going to O_CREAT so we’re getting a new file. I’ll try tomorrow with open(2) with O_WRONLY on it.