Re: [Boost-bugs] [Boost C++ Libraries] #11016: Boost file logging misbehaves when file system is full

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #11016: Boost file logging misbehaves when file system is full
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2015-02-24 07:52:44


#11016: Boost file logging misbehaves when file system is full
-------------------------------+---------------------
  Reporter: michi@… | Owner: andysem
      Type: Bugs | Status: closed
 Milestone: To Be Determined | Component: log
   Version: Boost 1.55.0 | Severity: Problem
Resolution: fixed | Keywords:
-------------------------------+---------------------
Changes (by andysem):

 * status: reopened => closed
 * resolution: => fixed

Comment:

> I just tried this, by adding keywords::open_mode = std::ios::app when I
 create the sink. But it doesn't appear to change anything.

 The newly generated file name must match the old file name, then it will
 append to the old file. This means that the file name must be sufficiently
 stable over time and not contain the counter. If you still can't get it to
 work, please, create a separate ticket.

> I'm sorry, but this is still not right. Once the file system fills up,
 boost log creates an empty log file on every file rotation. These empty
 files accumulate indefinitely and are never removed. That's a permanent
 resource leak.

 This is not a leak. Empty files, as well as non-empty ones are accounted
 for and deleted when threshold is reached. See the docs
 http://www.boost.org/doc/libs/release/libs/log/doc/html/log/detailed/sink_backends.html#log.detailed.sink_backends.text_file.managing_rotated_files,
 especially take note about the min_free_space parameter.

 I don't see the reason to change the behavior wrt empty files. They are
 not special and will be processed just like any other log file.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/11016#comment:27>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:17 UTC