Bug 190403 - RFE: the numerical suffix could support lexicographical sorting
RFE: the numerical suffix could support lexicographical sorting
Product: Fedora
Classification: Fedora
Component: logrotate (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Smetana
Depends On:
  Show dependency treegraph
Reported: 2006-05-01 18:51 EDT by Jiri TRAVNICEK, alias JITR {temporarily not reading bugmail}
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-07 08:50:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jiri TRAVNICEK, alias JITR {temporarily not reading bugmail} 2006-05-01 18:51:42 EDT
Description of problem:

When we add serial number suffix on rotated log files, it uses the default
format with minimum digits. If, according to the configuration, the serial
number exceed the range 0--9, we get suffixes with different lengths, which
don't sort lexicographically very well. For example, let's say we have the
suffixes in range 1--20, in which case the lexicographical order is (the prefix
`<base_name>.' stripped): 1, 10, 11, .., 19, 2, 20, 3, 4, .., 9. This, however,
doesn't correspond to the arithmetical order (or, if you, prefer, the age order).

While you may say I'm a purist (which I sometimes am), this is pretty annoying
when you try to examine the logfiles one by one, say in a file manager or with
less (by running, e. g. `less /var/log/access_log*').

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

1. Generate a log files listing (for a single log file and it's rotated versions
only, e. g. `/var/log/access_log*') sorted by name and then another sorted by
file age.
2. Compare the lists.

Actual results:

You should notice the discrepancy described in `Description of problem' above.

Expected results:

It should be possible to avoid the mentioned discrepancy. For proposed solution,
see the following section.

Additional info:

In order to avoid the sorting problem, the format of serial number extension
should be padded with leading zeros (or some other character, if someone things
of anything more appropriate).

The question is, what should the resulting length be after the padding. This
could be determined from the combination of `start' and `rotate' options. It
could also be configurable by a separate option, which would allow one to set a
length to a sufficient fixed value, which would be independent of any future
changes the the `start' or `rotate' options. The padding length should better
not change, otherwise logrotate wouldn't recognize already existing log files.
(This is already a problem with changing some other options as well, if I
understand it correctly.) If the padding length is less than the length of the
longest suffix according to the current configuration, logrotate would simply
exceed the configured length (like `printf(3)' does).

In order to maintain compatibility, the default would be not to pad, which would
correspond to the default value of 1 (or 0?).

Peter, please, tell me, whether you would consider such an enhancement
acceptable and if so, whether someone is willing to implement it or if it would
be added only if a patch is provided. In the later case, I'm willing to write a
patch myself, but not in the nearest future. So unless someone is faster, I
would do it myself in a few months, I guess...
Comment 1 Tomas Smetana 2007-04-19 09:37:31 EDT
The suffix already supports lexicographical sorting: using dateext option
together with rotate <num> will do exactly that. This may not work if you need
to rotate a log more often than daily, but this is not the likely case I'd say.
Is this OK for you?
Comment 2 Tomas Smetana 2007-05-07 08:50:38 EDT
Since the requested feature exists in logrotate and there is no activity on this
issue, closing.

Note You need to log in before you can comment on or make changes to this bug.