lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [lmi-commits] master 5567c43 1/3: Begin to tackle an observed


From: Vadim Zeitlin
Subject: Re: [lmi] [lmi-commits] master 5567c43 1/3: Begin to tackle an observed unit-test failure
Date: Mon, 17 Aug 2020 23:27:11 +0200

On Mon, 17 Aug 2020 20:44:13 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> The reported failure arose because user 'nemo', with some default
GC> group like 'nobody' that no one else belongs to, ran the unit test,
GC> creating a directory with a static name that everyone else had to
GC> use (in order to run a particular unit test), but no one else had
GC> permission to use it. Was the problem that...
GC> 
GC>  (1) the temporary directory's name was static?
GC>      (then mkstemp() would be the solution); or
GC> 
GC>  (2) user 'nemo' had a default group that no one else belongs to?
GC>      (then its default group should be changed to 'lmi'); or
GC> 
GC>  (3) the notionally "temporary" directory was physically permanent
GC>      because I failed to remove it? (then filesystem::remove() is
GC>      the solution)
GC> 
GC> I started by addressing (1), just because it came to mind first.
GC> Then I skipped (2) because (3) occurred to me, and now I think that
GC> failure to remove that directory (i.e., (3)) was the cardinal sin.

 Hello,

 I agree that (3) is the underlying problem, but you can't always ensure
that it is removed without using some outside supervisor (in modern Linux
this means systemd) because the program can always be just killed, e.g.
it's relatively common for the unit tests to be debugged and it's enough to
quit the debugger without letting the program run to its end for the
temporary directory to be left on disk.

 So IMO (2) is still a problem too and my solution would be multi-pronged:

- Create the directory using lmi group.
- Remove the directory on program exit (even if it exits abnormally).
- Also remove the directory on program startup if it still exists.

GC> As for (2), I figure it can wait: it seems like a prima facie defect,
GC> but it unmasked real problems, so maybe it's a "feature".

 This logic seems suspicious to me, I don't think anything that results in
a bug automatically shouldn't count as a bug on its own.

 Regards,
VZ

Attachment: pgphQ5u51YiZq.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]