Re: [9fans] p9p vac/vacfs compatibility: uid/gid, ctime, 9P2000.L, 9pserve

[David du Colombier <0intro@gmail.com>]

> When I mount the file system, all the files are owned by uid = gid =
> (-2 mod 2^32), unless I tell the Linux kernel to mount the fs as a
> specific user/group.  In the latter case, all files present with the
> specified user/group (as expected).  I can't find any way to get at
> the actual uid/gids owning the files/directories vac'd.  I have tried
> explicitly specifying -o version=9p2000.u, but it exhibits the same
> symptoms: all files and directories appear to be owned by uid = gid =
> (-2 mod 2^32). All uids/gids in the vac'd tree existed
> in /etc/{passwd,group} at the time of vac'ing, as well as at mount
> time.

The problem you are encountering is that v9fs doesn't translate
uid/gid strings back to their numeric equivalent in /etc/passwd.
Since Unix doesn't know how to handle these strings, it falls
back to -1.

Forget about 9p2000.u, it's deprecated.

> So, the source *appears* to stow uid/gid to venti as character
> strings.

This is the case. You can show the actual uid/gid from the
Plan 9 vacfs and even on p9p, using vacfs -d.

> Does this mean that vac doesn't store ctimes on p9p?
> Shouldn't this be wrapped in something like:

Yes, vac doesn't store ctime. Maybe we could store it in vac,
as you suggest, but 9P doesn't handle it anyway.

> Those dir.uidnum and dir.gidnum don't appear to be referenced anywhere
> else in the code.

I never paid much attention to it. It looks unused.

> But it makes me wonder... are the character string
> uid/gids vac'd the textual names from /etc/{passwd,group}, or just
> ASCII versions of the numeric ids, a la format "%d"?

They are the textual names.

The problem you are describing is not related to vac nor vacfs.
They both handle uid/gid properly, and, as you saw, p9p vac can
even translate numeric uid/gid to their string representation.

--
David du Colombier