pv-tree-copy: Document EXPECT_HARD_LINKS flag
Fixes: b5441dc6 "pressure-vessel: Warn if we have to fall back to copying"
utils: Add _srt_stat_get_permissions
This is just syntactic sugar for something we do quite often.
pv-mtree: Don't log repeated warnings if unable to set lots of mtimes
If the filesystem or file ownership doesn't support setting the mtime, all of them will fail in the same way, leading to a lot of log-spam. In particular, this is likely to happen on NTFS or when operating on a directory owned by a different user.
pv-mtree: Factor out maybe_chmod()
I'm going to extend this to cope better with filesystems where we do not own the files or otherwise cannot change their ownership, and that will be easier if we can early-return on success or if there is nothing to do.
pv-mtree: Give a clearer error message if unable to chmod
If we can't chmod the file, we should say what the current owner and permissions look like, to assist debugging.
In particular, this is likely to happen on NTFS or when operating on a directory owned by a different user.
For example, if the filesystem is owned by root (steam-runtime#544) we might say:
Unable to change mode of ... from 0777 (owner: "root", group: "root", non-member) to 0644: ...
or if the file is owned by the current user but the filesystem does not allow chmod anyway (steam-runtime#606) we might say:
Unable to change mode of ... from 0755 (owner: current user, group: "users") to 0644: ...
pv-tree-copy: Factor out link_or_copy_regular_file()
pv-tree-copy: Factor out copy_regular_file()
pv-tree-copy: Use a lower-level implementation of copying regular files
This gives us more control over which operations we will allow to fail, which is important if we want to cope with filesystems where fchmod() can't work, for example NTFS or a directory owned by a different user.
pv-runtime: Tolerate inability to chmod files if the permissions look OK
It is somewhat common for Steam-on-Linux users to have their default Steam library on an NTFS drive: even though this is not really recommended, a dual-boot system could have most of its available space formatted as NTFS. In this case we still try to set the permissions we wanted, and show a warning if we can't; but as long as files and directories that we want to be executable are executable, and other files are at least readable, we might as well try to continue and see whether it works.
Similarly, it is somewhat common for users of multi-user systems to have a Steam library that is owned by one Unix user, but writeable by another Unix user and shared by both. This is not a recommended setup, because the inability to chmod the other user's files will frequently break expectations, and it removes any effective privilege separation between the users, hence requiring the users to trust each other completely (each user can cause arbitrary code execution for the other by overwriting a game binary). However, some users do this anyway, both on Windows and Linux, and expect it to work. As with the NTFS case, we can try to proceed and hope for the best.
Note that this change specifically does not affect having Proton installed in a location not owned by the current user, which will still not work. Wine has a specific check for the wineprefix being owned by the current Unix user (which is known to cause problems), and will refuse to run if it is not.