Your message dated Sat, 15 Mar 2025 13:49:27 +0100
with message-id <[email protected]>
and subject line Re: Bug#673149: tmpreaper: protect on directory fails. Invalid 
process order.
has caused the Debian Bug report #673149,
regarding tmpreaper: protect on directory fails. Invalid process order.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
673149: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673149
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: tmpreaper
Version: 1.6.13+nmu1

On Wed, 03 Aug 2011, Mick Switser wrote:
> The solution:
> Put the protect match check block (if (FLAGS_PROTECT_P (flags)) {) before
> the recursive directory check block (if (S_ISDIR (sb.st_mode)) {).

I fully agree.  I also needed to protect a complete subdirectory of
/tmp, read the tmpreaper source to be sure it works the way I *expect*
it to deal with this case, and ended up with the very same conclusion.

Paul, please apply this patch.  It picks the safe (and more useful) of
the two possible interpretations of the --protect parameter (i.e.,
protects all files within a protected subdirectory from being deleted).

-- Horst

-- 
PGP-Key 0xD40E0E7A



--- End Message ---
--- Begin Message ---
On Wed 16 May 2012, Horst Schirmeier wrote:

> Package: tmpreaper
> Version: 1.6.13+nmu1
> 
> On Wed, 03 Aug 2011, Mick Switser wrote:
> > The solution:
> > Put the protect match check block (if (FLAGS_PROTECT_P (flags)) {) before
> > the recursive directory check block (if (S_ISDIR (sb.st_mode)) {).
> 
> I fully agree.  I also needed to protect a complete subdirectory of
> /tmp, read the tmpreaper source to be sure it works the way I *expect*
> it to deal with this case, and ended up with the very same conclusion.
> 
> Paul, please apply this patch.  It picks the safe (and more useful) of
> the two possible interpretations of the --protect parameter (i.e.,
> protects all files within a protected subdirectory from being deleted).

Hi,

While going through the list of bugs, it seems that this was already
fixed as #636459 in 1.6.14+nmu2, so closing this report now.


Thanks,
Paul

--- End Message ---

Reply via email to