Hi Matthew, > I think the FHS is basically just writing what is generally expected > practice of _any_ cache: it's possible (even expected) for there to be > cache misses, and the application should be able to deal with that. If > that's not the desired behavior, it's probably better to use some > other location.
And a program, having had a successful cache hit when opening a file by name earlier in its invocation, should have no expectation that a second access by name should work in that invocation? That's my reading of http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s05.html. If there's notes on what might change in a future FHS revision, could something be added to explicitly point this out as I expect it's a common bug with /var/cache users of moderate complexity. What would be a reasonable thing for a package manager to do? Mats Wichmann said on this thread that he'd hit the same problem with Fedora's yum as I did with Arch Linux's pacman. It seems that if a clutch of package files need to be installed as as group for a coherent upgrade then they could be moved to "safety", e.g. /var/spool, for the duration, allowing them to be repeatedly opened by name, including by other helper programs, returning to /var/cache after installation for reference, re-install, or later downgrade. Or else open(2) once and refer strictly by file descriptor from then on, as I suggested before. Cheers, Ralph. _______________________________________________ fhs-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/fhs-discuss
