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

On Mon, 3 May 2021 19:35:58 +0200
Denis Corbin <[email protected]> wrote:

> 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.

As did I.  I must have had a typo in my grep -R attempt, because it
didn't find it.

> 
> @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.

I agree - the sockets are more a nuisance than anything critical. I also
agree that applications will tend to recreate them as needed.

For that particular user I was testing, I put a line in their logout
script that deletes that xpad socket so I can test if that impacted the
reappearance of xpad notes at login - and it did not. I will leave that
deletion there for now while I experiment with the EA-tagging technique
that Denis suggested for other sockets (or generalize the deletion of
sockets at logout). Thanks for that idea, Denis!

I will stay away from building my own version of dar for now at least.

As long as this is just a problem with sockets, it is manageable.
Another likely source of sockets in the homedir is in .gnupg, which I
found in another user's homedir that I have not tested yet.  I suspect
that gnupg won't mind if they are deleted at logout, but at least I
have the EA-tagging technique if I need it.

Even if the sockets do need to be recreated on extraction, I can always
back them up separately to a flat text file along side running dar with
the EA-tagging.  The same find -s that adds the EA tag can write their
encrypted pathnames and attributess to a text file.

Thanks again Denis, and thanks to Mihai as well.