The current behavior I’m guessing has existed since the lfs find command was introduced so there’s probably a lot of user code and external software built around the current behavior. That could all break in ugly ways if the default unit is changed to a value that’s 512 times larger than :)
Perhaps a ‘--gnu-compatibility’ flag to lfs find with a warning in the man page about the differences between GNU find and LFS find would be sufficient. That way the options to lfs find whose behavior have deviated from gnu find (such as size and the issue Peter mentioned) could be toggled to the GNU find behavior in situations where that’s the desired effect but we don’t break any existing scripts or code. Sent from my iPhone > On Nov 5, 2023, at 07:35, Peter Grandi via lustre-discuss > <lustre-discuss@lists.lustre.org> wrote: > > >> >>>> On Sun, 5 Nov 2023 06:13:52 +0000, Andreas Dilger via >>>> lustre-discuss <lustre-discuss@lists.lustre.org> said: > >> I've recently realized that "lfs find -size N" defaults to >> looking for files of N *bytes* by default, unlike regular >> find(1) that is assuming 512-byte blocks by default if no >> units are given. [...] > > I think that compatibility with 'find' matters a lot, so I > support the proposed changes. > > Also note that 'find' has a bizarre rule about rounding up to a > whole multiple of the given unit, which 'lfs find' regrettably > ought to do too if it does not already. > http://www.sabi.co.uk/blog/23-one.html?230117#230117 > > BTW I was about to report a problem specific to 'lfs find': > > --mirror-state ro -a --mirror-state wp -a --mirror-state sp > > only tests "sp", the two previous tests for "ro" and "wp" have > no effect. This has caused me problems because I was trying to > run 'lfs resync' only on files that are "^ro" and also "^sp" and > not "^wp", and this seems impossible in a single 'lfs find'. > > It looks to me as if '--mirror-state' behaves as an *option* > ('find' has "options", "positional options" and "global > options") and not as a *test*. At the very least this should be > prominently documented. > > This might be hinted by having "xx" and "^xx" forms, which > suggests that these two are not equivalent: > > ! --mirror state ro > --mirror-state ^ro > > which would make sense if "--mirror-state" is an option. > _______________________________________________ > lustre-discuss mailing list > lustre-discuss@lists.lustre.org > http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org _______________________________________________ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
