Date: Fri, 24 Aug 2018 23:27:41 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 230851] fsck sets last modified file size to zero on crash on UFS filesystem Message-ID: <bug-230851-3630-P5c1TCw4UI@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230851-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-230851-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230851 Kirk McKusick <mckusick@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Not A Bug --- Comment #3 from Kirk McKusick <mckusick@FreeBSD.org> --- (In reply to Ali Abdallah from comment #2) I have looked at nano and it does not follow the proper protocol for writing out the file (which is detailed in my comment #1). It simply does: fd = open(file, O_WRONLY|O_CREAT|O_TRUNC, 0666); write new contents close(fd); The O_TRUNC flag truncates the file to zero length. If the system crashes before the new contents are written, you get a zero length file. By default the contents will not be written for up to 30 seconds. So if you panic within 30 seconds of the file being written, you will get a zero length file. The proper way to fix this is detailed in my comment #1. The gap could be closed significantly by adding an fsync(fd) before calling close as that would cause the file to be written to disk within a few milliseconds of its finishing being written thus closing the gap considerably (but it would still be possible to get a zero length file). So, it really should be fixed properly. I am closing this bug because it is a bug in nano and not in FreeBSD. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230851-3630-P5c1TCw4UI>