Hmm, how would the effective behavior of this differ from directly returning the path? The symlink could become invalid at any time, and it would become invalid in precisely the same scenarios that the original file would. A further request would in both cases stat the original file, and if it were missing, download a new copy into the cache via the usual mechanisms.
It would make sense if the cache were made to contain a hard link to the file if it were on the same filesystem as the cache, but that inherits the usual problems with hard links. It would persist a copy of the file in the cache though. On Thu, Jun 1, 2023 at 7:58 AM Frank Ch. Eigler <f...@redhat.com> wrote: > Hi - > > > So I guess, sans the format, the feature request would just be that > > it would have a shortcut for file URLs to produce the path directly > > in response to e.g. a debuginfod_find_debuginfo, rather than making > > a copy of the file via libcurl. > > A compromise solution could be for new code to produce a symlink in > the .cache/debuginfod_client directory that points to the matching > file:// bit, and return that symlink name/fd to the calling app. > > At future accesses, the client can determine if the symlink is > broken and reject/unlink it. > > - FChE > > -- Daniel Thornburgh | dth...@google.com
