Well, not really because it is set false at the start (well initial
state). Let me explain the state:
a) we find a CRL, the state is set to true.
b) second scan and we don't find a CRL.
c) What do we do? Two cases:
1) The previous file is kept so it's OK to say use the CRL.
2) The previpus file is replaced with a null file -- not OK.
I think you see the conundrum. It really depends on what happens to the
compisite CRL file; i.e. is it kept or replaced. So, given that I don't
know (as a reviewer) it seems safest to just reflect the current state.
Now, you can elucidete what the case is. However it should be made
painfully clear in the comments ahead of the test; otherwise we will be
revisting this for years to come.
Andy
On Wed, 1 Dec 2021, ccaffy wrote:
> @ccaffy commented on this pull request.
>
>
>
>> @@ -198,11 +209,17 @@ CRLSet::processFile(file_smart_ptr &fp, const std::string &fname)
> return false;
> }
> }
> + if(!m_atLeastOneValidCRLFound)
> + m_atLeastOneValidCRLFound = atLeastOneValidCRLFound;
>
> Ok, I see what you mean. I just need to reset this boolean to false at the beginning of the Maintenance run :+1:
>
> --
> You are receiving this because you commented.
> Reply to this email directly or view it on GitHub:
> https://github.com/xrootd/xrootd/pull/1547#discussion_r759989747
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/xrootd/xrootd/pull/1547#issuecomment-983463084
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
