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=3D230851 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 =3D 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 pro= per 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 cau= se the file to be written to disk within a few milliseconds of its finishing b= eing 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. --=20 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>