Bug 181309 - gzip(1) can leave corrupt files lingering around a filesystem in the event that a signal != SIGINT was received or the program exited in before completeing the file_compress function
Summary: gzip(1) can leave corrupt files lingering around a filesystem in the event th...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-14 22:20 UTC by Enji Cooper
Modified: 2017-12-31 22:27 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Enji Cooper freebsd_committer freebsd_triage 2013-08-14 22:20:00 UTC
We have a number of bugs filed for newsyslog compression failure issues open at work due to panics at the time of log rotation, and the like. I did some code inspection and I realized that there are some design flaws with gzip(1). In particular:

1. gzip doesn't use mkstemp and it really should (not using mkstemp means that multiple accesses to the same file can create corrupt gzip files potentially or result in unexpected behavior). renames of the gzip'ed content to a temporary file are guaranteed to be more atomic than writing out to the file itself.
2. It's assumed that if the file_compress function will run to completion, and in which case files can be deleted (which is indeed not the case with some of the code paths in gz_compress that call maybe_err*).
Comment 1 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:54 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped