Re: error restoring Unix socket ... path too long to be stored properly

On 03/05/2021 04:20, Mihai Moldovan wrote:
> * On 5/3/21 12:42 AM, imschmeg wrote:
>> On Sun, 2 May 2021 22:51:14 +0200
>> Is there any way to override the value dar uses in place of
>> UNIX_PATH_MAX?
> 
> If you really want to go ahead and try it yourself, there are quite some places
> where dar defines this macro, but only one place where it's actually being used:
> 
> src/libdar/filesystem_hard_link_write.cpp:
> strncpy(addr.sun_path, name, UNIX_PATH_MAX - 1);
> src/libdar/filesystem_hard_link_write.cpp:
> addr.sun_path[UNIX_PATH_MAX - 1] = '\0';
> 
> So, if you feel brave, modify the source code, rebuild dar and hope that
> whatever you did is compatible with your system.
> 
> 
>> It seems that it isn't defined in Debian.
> 
> But it is. See /usr/include/linux/un.h, part of linux-libc-dev.
> 
> 
>> This is just in case I hit this issue again with backups of this kind
>> of encrypted file system, where I have no control over pathname length.
> 
> Likely not worth the hassle. You can still skip unrestorable files and
> attributes manually or even automatically, right?
> 
> 

Thanks you Mihai for pointing us to the system header, I failed to find
yesterday.

@imschmeg
If you can effectively modify libdar's source code and increase the
UNIX_PATH_MAX at the top of src/libdar/filesystem_hardh_link_write.cpp
to a higher value, (removing the #ifndef UNIX_PATH_MAX / #endif around
it to bypass system value), you may well get unexpected behavior for
Debian system in particular as this value defines the maximum length of
the data-structure the system expects to have...

The restriction with dar is that it does not "change of directory". This
would be inefficient and sometime impossible (lack of ownership to 'cd'
but enough to write to a directory for example: drw-rw-rw-), so the path
leading to a socket may become large, while the application that created
the socket had probably created it from the parent directory.

Well, anyway, saving and restoring unix socket is not very crucial: the
daemon or program listening on it will most of the time recreate it when
launched.

> 
> Mihai
> 
> 

Cheers,
Denis