On Tue, 10 Oct 2023 at 20:15, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > It may not be me, it may be someone else, so there is a limit to my > commitment, but kernel developers usually abide by Linus' no regressions > rules (which do allow some slack). Note: the no regressions rule is about actual "out in the field" regressions, not about potential or theoretical regressions. My guess is that changing the escaping rules for workdir and upperdir would not make any difference. Look: on my laptop 0.0032% of filenames contain a backslash. How likely is such a filename to be used as workdir or upperdir? So yes, I think getting rid of unescaping for these parameters on the new API is safe and will not invoke the no regressions rule. The same cannot be said of lowerdir, because the incidence of colons in filenames is much higher. But the new API also introduced an "append mode" for lowerdirs, where the colon doesn't have the same separator role as with the "bulk mode". Unfortunately it's not possible to clearly differentiate the two modes, which I think is a downside of the current design, and it's why I suggested the _noesc variants. > > Anyway, let's focus on what you would like best. > If you prefer to just fix the regression, it is doable. > If you prefer the upperdirfd, workdirfd, lowerdirfd API, I think we can > find a volunteer to write it up. It's not all good: when showing these options, the result is completely meaningless. Or is there a plan to make that work nicely? THanks, Miklos
