On Wed, 2019-12-11 at 05:54 -0500, Doug Nazar wrote: > On 2019-12-09 23:49, Ian Kent wrote: > > I also need to work out why you don't get caught by the negative > > map entry check that's meant to prevent multiple retries for a > > failing map entry for a configured time. > > Sorry, I should have been more explicit. The several minute wait was > to > exceed the negative cache timeout. That part was working fine. > > > > And even the entry delete below it should be ok because it will > > > just lookup (aka. run the program map again to get the map entry) > > > and then update the multi-mount during the entry parse. > > > > > > So while the change above isn't strictly the way this should be > > > handled it probably should be ok. > > > > > > I haven't worked out how to handle it immediately after the fail > > > just yet but the change above probably should be kept as part of > > > that as well, not sure yet. > > > > > > Ian > > I did that based on my greps, that seems to be a fairly common > check. > However, it kind of felt wrong, in the sense that the 2nd attempt, > shouldn't depend on any previous status. I was just having trouble > trying to figure out the lifetime rules for the various > fields/states. Yes, the root of a multi-mount has all sorts of special case handling in a number of places. > > Thanks, > Doug >
