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

On 02/05/2021 20:47, imschmeg wrote:
> On Sun, 2 May 2021 14:01:54 -0400
> imschmeg <[email protected]> wrote:
> 
>> I am getting this error during extraction of an archive of an
>> encrypted file system (each file and its filename are encrypted
>> separately, that's why the long jibberish filenames). The source and
>> destination are the same f2fs file system on Debian stable 10.9.  The
>> original socket name works, so why can't dar extract that same name?
>> Is this a problem specific to sockets?  Is it a problem with dar's
>> understanding of the f2fs filesystem?  There are many other much
>> longer pathnames in this backup that were extracted without issue,
>> but this was the only socket.
> 
> BTW: this is not a critical error for me.  I was able to track down the
> particular socket (it being a bit unusual that a user would have a
> socket in their homedir), and it was due to that user's use of xpad:
> .config/xpad/server. Turns out that this socket can be deleted when
> xpad is not running without any problems.  I think this is typically
> the case with any sockets a user might store in their homedir, so I
> will not back them up.  Is there a way to exclude all sockets when
> creating a backup with dar?
> 

no today, but that would make sense to add a new feature for that.
I'm adding that to the todo list.

In the meanwhile you can filter by filename (-X option) or path (-P
option) for example.

Another solution is to avoid saving sockets. If you have extended
attributes available on your filesystem, you can flag all unix sockets
with the specific EA "user.libdar_no_backup" then add --exclude-by-ea
option to dar at backup time.

which could done this way:

find /some/path -type s -exec setfattr -n user.libdar_no_backup {} \;
dar -R /some/path --exclude-by-ea -c backup ...

instead of "user.libdar_no_backup" you can use a different EA, see
--exclude-by-ea description in man page for more details.

Cheers,
Denis
>