Re: Local Build ID Directory Lookup (DEBUGINFOD_LOCAL_PATH)

[Daniel Thornburgh <dthorn@google.com>]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

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 <fche@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 | dthorn@google.com