Bug 44643

Michal:

On what occasion could this happen?  I can't seem to trigger repeat behaviour and I'm 
not sure what your fix accomplishes besides matching longer filenames?

This error happens when /var/log/sa exists ('sysstat' package was
already installed), and cron runs (think 'ancron') but no information
was recently collected for whatever reasons (you just installed the thing, or
it was turned off recently because of something, or this is a laptop
which was dormant for two weeks, or ... ).

You can likely provoke it by turning off 'systat', "rewinding" timestamp
on /var/log/sa with 'touch -d ...' and waiting for cron. :-)

The point of a proposed change is exactly to match longer names as then
/var/log/sa directory itself will not match but data files with names
like 'sa<something>' and 'sar<something>' will do - if they exist.
Actually a pattern 'sa?*' should be good enough for everything.
Normally you do not try to remove /var/log/sa because if 'sysstat'
is active then it has a recent timestamp and not because you did not
match the name.

This is rather minor and it can be dismissed with "Do not mess with toys
you do not have a business with" but this seem to me to be contrary to
a general attitude of the whole distribution. :-)

This defect considered SHOULD-FIX for Fairfax gold-release.

Doesn't make sense to me.

[pbrown@dionysus SPECS]$ touch -c -d 19990101 /var/log/sa
[pbrown@dionysus SPECS]$ ls -la /var/log/sa
total 8
drwxr-xr-x    2 root     root         4096 Jan  1  1999 .
drwxr-xr-x    4 root     root         4096 Aug 13 16:00 ..
find /var/log/sa \( -name 'sar??' -o -name 'sa??' \) -mtime +7
[ no output ]

Because the wildcards ?? are not getting matched.

? is defined as "matching any single character."  I.e. sa?? cannot match sa.

Are you sure you have properly defined the problem?

Use whatever pattern which will match data files but it will NOT match
'sa' by itself.  If you prefer you can use '! -type d', if you want
to be on a safe side.  As data files have names which have at least
three characters long then you can use "-name 'sa?*'" and this will
not match /var/log/sa.  Data files happen have names 'sa' or 'sar'
followed by two digits.

Whatever.  The point is that we do not want to attempt to remove
/var/log/sa regardless how time-stamps happen to look at the given moment.
The underlying problem is that original assumes that /var/log/sa is
"new enough" to prevent that and this is not always the case.

This is not a very big issue until you will try 'rm -rf' but it generates
"garbage mail" to root in some circumstances.

Please read my comment, I still don't see how what you reported was possible.  
Not saying it didn't happen, but not understanding how it was possible. -name 
sa?? -o name 'sar??' should _never_ have matched a file/directory named just 
'sa'.

> Please read my comment, I still don't see how what you reported was possible.

Sigh!  I thought that I was clear enough.  Let's try this way.  Drop time clause
from the original 'find' pattern and try yourself to see what this will match.
You will get /var/log/sa itself on this list as well. If for whatever reason
(I mentioned some possibilities) /var/log/sa has a time stamp which will
not eliminate it from a match with a full pattern then you will attempt
to remove it and here comes an error message.  In "normal" operations a time
stamp on /var/log/sa will be recent enough to prevent a match but not always
a situation is "normal".  Once again - this is not a big deal but any of
alternative cures is equally simple.

sorry, I was looking at the wrong regexp.

We do now have a better regexp for the 7.2 version (sysstat-4.0.1-2).