rsync'd files&dirs saved as user:group = "unknown":"unknown", NOT original ownership

[snowcrash+rsync]

hello,

> > but, although the creation times/dates are maintained, the user:group
> > are NOT ... changed, instead to "unknown":"unknown"
>
> Since you specified that users & groups should be transferred using
> numeric IDs, you should check to see what the IDs are on the files.

the IDs for users & groups are sync'd across all my boxes, as

  uid(root)  = 0
  gid(wheel) = 0
  uid(unknown) = 99
  gid(unknown) = 99

> Also, do a copy using 4 verbose options (-vvvv) and you will be shown
> what each side believes to be the file-list information.  This will
> include the string "uid=1234" on the sending side (no matter what),
> but the receiving side's list will only contain this string if rsync
> believes that it is running in super-user mode with ownership being
> preserved.

while rtfm'ing and poking around, i believe i've stumbled onto the
problem -- or, at least, a causal component.

the boxes -- in this case -- are OSX boxes.

at one time, the DST /Volume had been set to "ignore ownership on this
volume" (iirc, newly formatted disks default to this setting (??))

when the volume had been switched to NOT ignore ownership, the
Volume's root dir ownership (i.e., @ "/Volumes/volume_name") --
apparently -- remained at unknown:unknown -- despite hierarchically
deeper dirs being spec'd as specific IDs (root, wheel, etc).

until using rsync, i don't think any app i'd used to touch that volume "cared".

that said, apparently as long as that "/" ownership remains at
unknown:unknown, rsync creates was creating as unknown:unknown --
regardless of the cmd line opts.

once i've toggled the "ignore ownership" ON-OFF, 'landing' at NOT
ignoring ownership ... now, the same rsync cmd *correctly* reproduces
the ownership of the SRC files.

so,

-- i've learned a bit about rsync
-- i've learned a bit about my boxes
-- hth someone else!

thanks!