Store and apply actions fail when user or group ID of some dirs/files in file system has no entry in password or group database

[krichter722]

That's not ideal for usage with git as backup program since it shouldn't be necessary to have a file owner present on the system where the backup is created.

Failure is assumed from the text of the warning. In case that's just a warning, it needs be improved and/or labeled in order to sound like a warning.

[przemoc]

Well, it depends on the kind of backup you're actually doing. One thing is sure, I won't change the behavior for upcoming v1.1. There are two reasons:

• v1.1 won't have behavioral changes,
• you cannot store uid in current metastore format, because it uses names by design.

That said, I'm open to tune it in the future. Configuration (#7) and textual format (#6) will be needed for that.

[smemsh]

Definitely good idea. Just had occasion for this yesterday: ran a script that was supposed to recursively change permissions in /etc/something/ but it had a bug that caused it to start in /etc/; had to restore permissions from backup.

However the backup machine had a totally different /etc/passwd; I had done my backup using rsync --numeric-ids. Unfortunately, lack of support for this operation in metastore made this impossible (it does getpw* calls and bombed).

I had to use getfacl | setfacl instead.

[insanityinside]

Moved from bug #41 - Attempting to apply metadata to a filesystem where the current UID/GID is not in /etc/passwd results in a "getpwuid failed" error on startup, and a failure to change the ownership of the files specified in .metadata, with a "removed" message when the files were actually there.

(Situation occurred after running an rsync from a host when restoring, and the UID/GID in question restored by rsync was a different UID/GID to the original.)

[moskalenko]

It looks like this issue is still present in metastore. Any plans to resolve it? Thanks.

Here's running it from a git hook:

getpwuid failed for .: uid 1005 not found