Lots of Character Device Files/Sockets in diff folder under Graphroot

[stellarpower]

Hi,

I'm moving my graphroot* from one disc to another. I did an initial copy using tar and then am sanity-checking before I wipe the old disc, using Unison as I quite like the UI.

* (I'm actually moving a whole disc, and some of this includes emergency backups, so this may be because things were in an unclean state when I backed up)

Unison is complaining it is finding quite a lot of files of unknown type. When I stat these, they have all seemed to be sockets or device files. The error message is a bit odd, but I know Unix sockets that have not been cleaned up are meaningless to be copied from one folder to another and can safely be ignored when taking a tarball. Device files also, but more complicated but aren't data per se. Maybe it says it in this way because it's not meaningful when syncing files.

What is interesting is that some filenames have indeed been things I think I can safely ignore - e.g. a halfway-unpacked debian package, or something that clearly appears to be a socket or a temporary file. It's possible a user has saved a running container that hadn't quite finished installing or was still running a server process or something. Either case, it can probably be ignored.

However some filenames do seem unusual for a special file. I see dynamic libraries and plaintext/system filenames that when I stat them, are device files or sockets, in the source folder:

  File: ....local/share/containers/storage/overlay/03dfa661a7857ceb11b34061ffa58f9a560db6b455ad448315cf1b5c79702751/diff/lib/x86_64-linux-gnu/libpthread-2.28.so
  Size: 0               Blocks: 0          IO Block: 4096   character special file
Device: 254,2   Inode: 117649881   Links: 1     Device type: 0,0
  
  File: ....local/share/containers/storage/overlay/03dfa661a7857ceb11b34061ffa58f9a560db6b455ad448315cf1b5c79702751/diff/lib/x86_64-linux-gnu/ld-2.28.so
  Size: 0               Blocks: 0          IO Block: 4096   character special file
Device: 254,2   Inode: 117649831   Links: 1     Device type: 0,0
  
  File: ....local/share/containers/storage/overlay/03dfa661a7857ceb11b34061ffa58f9a560db6b455ad448315cf1b5c79702751/diff/usr/bin/apt-file
  Size: 0               Blocks: 0          IO Block: 4096   character special file
Device: 254,2   Inode: 117649901   Links: 1     Device type: 0,0

 File: ....local/share/containers/storage/overlay/03dfa661a7857ceb11b34061ffa58f9a560db6b455ad448315cf1b5c79702751/diff/var/lib/dpkg/info/apt-file.md5sums
  Size: 0               Blocks: 0          IO Block: 4096   character special file
Device: 254,2   Inode: 117650942   Links: 1     Device type: 0,0

 File: ....local/share/containers/storage/overlay/0eb840fdc429e600ea0265fd2e325ab4359659820e089c36eab1a42aff248e35/diff/run/.containerenv
  Size: 0               Blocks: 0          IO Block: 4096   character special file
Device: 254,2   Inode: 110837441   Links: 1     Device type: 0,0

File: .../.local/share/containers/storage/overlay/d941ee07d19c887f723ff0187e62ae641cd1e77b9d362921195a34ed6aca02d0/diff/root/build/opengv/.git/modules/python/pybind11/HEAD.lock
  Size: 0               Blocks: 0          IO Block: 4096   character special file
Device: 254,2   Inode: 251467240   Links: 1     Device type: 0,0

  File: .../.local/share/containers/storage/overlay/07678931ff7da8b24b3cff3cb644b908f05b16c242a1829017763a43973bc2c2/diff/usr/include/boost/thread/cv_status.hpp.dpkg-new
  Size: 0               Blocks: 0          IO Block: 4096   character special file
Device: 254,2   Inode: 283971864   Links: 1     Device type: 0,0

They all seem to be in the diff folders (working changes overlay-mounted on top of the last layer in the image?). I was just wondering if in any way this is expected, or there's a known reason this might occur. I'm a bit loathe to wipe the original disc if plain text files or core libraries like pthread are not copied as they're showing up as device files for some reason. Are device files sometimes cropping up when containers aren't cleanly shut down something to be expected, or do I need to probe to see if there is an issue on my system here, as my gut feel would be?

Thanks a lot

[Luap99]

These are whiteout files from overlayfs so yes you need them for the container file system to look correct, https://docs.kernel.org/filesystems/overlayfs.html#whiteouts-and-opaque-directories

However in general I would not recommend to back the container store at all. All persitent data should be on volumes and only they should be saved. The images should be pulled again and the containers recreated when migrating data IMO but of course a full 1 to 1 copy should also work (if it was done atomic and did not backup some partial state, i.e. while the source changed)

[stellarpower]

Perfect, thank you! Was aware stuff like that is happening but didn't know the exact term, now I do. It's all devcontainers etc. on this machine, so unfortunately very far from following the ephemeral concept! I will make sure I mirror them across somehow, and had forgotten about xattrs so cheers.