Re: lib/INS@d2fRCK ?

On 2024-12-15 09:24, Roger Marquis wrote:
> Fingprinting a staging jail with 14.2 shows a half-dozen new files that
> didn't exist in 14.1 but one in particular, without a man page, that is
> unlike the rest:
> 
>    # file lib/INS@d2fRCK
>    (ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), 
> dynamically linked, for FreeBSD 14.2, stripped)
> 
> Checksums indicates it is a copy of libmt.so.5:
> 
>    # md5sum lib/*
>    4987e6ba61e36eeff23de3acaa4ee771  lib/INS@d2fRCK
>    4987e6ba61e36eeff23de3acaa4ee771  lib/libmt.so.5
> 
> Questions are:
> 
>    a) is it safe to delete,

Should be.  INS@XXXXXX was created by install(1) and decided by mkstemp. 
  They should be cleaned up after a successful or failed install(1) 
invocation but may be left over if install(1) was killed by force.

>    b) what buildworld delete-old{,-libs} or etcupdate function might 
> have created it,

I think it's make installworld.

>    c) should I be checking for other apparent tempfiles, and
>    d) if so, how?

For this particular case you might want to find all files named 
INS@?????? ; however it seems that something(TM) might happen in the 
middle of install process.

My knee reaction was "we should probably install an atexit / signal 
handler after mkstemp() call to perform cleanup" but that would still 
have some race windows left open.

Cheers,

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQS7JJNqVzWrbGqXjc8RA+Lrl1nkxQUCZ19D9gUDAAAAAAAKCRARA+Lrl1nkxapQ
AQD5uFuOdN0PnPGN1aLNK3jWv/awoaP+QnWmYNxi5VQp3QEA7gesvzzRhUh2rcf+lWDjhQYououL
QnYdQZPPCVS+uQg=
=AGZC
-----END PGP SIGNATURE-----