> 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
