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):

logrotate-3.7.3-3


How reproducible:

always


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...