File owner name not updated.

Matthew Seaman m.seaman at
Wed Mar 26 07:29:30 PST 2003

On Tue, Mar 25, 2003 at 10:55:03PM -0800, Kevin Stevens wrote:
> I had this problem several months ago, submitted a bug report on it, 
> and promptly forgot about it.  I'm now seeing the same issue in 5.0, 
> and want to delve a little deeper to see if this is expected behavior 
> or not.
> I created a user, let's call him fred, which was assigned uid 503.  The 
> user directory was created and assigned to owner fred and group wheel.  
> All ok.  Later that evening, root changed the uid for fred to 502 (for 
> compatibility with other systems).  The problem isn't that the 
> directory owner didn't automatically change to uid 502 - I expected to 
> have to change it manually.  What I wasn't prepared for is that a ls 
> -al still showed the owner as fred, which was now assigned to uid 502.  
> ls -lan properly showed the owner as still being 503.
> So, I'm open to correction, but it seems to me that something's broken. 
>  If user fred used to be 503, but is now 502 (there is no user 503 
> now), I don't see how it can be correct for ls to still report fred as 
> the owner of files/directories.  I expected the reporting to change to 
> just show the numeric uid, but I'm not picky about that.
> I have no idea whether this is a problem with the ls command, with the 
> filesystem, with some index of ownership/permissions, or something else 
> entirely.  Suggestions?

Two things occur to me:

    i) Did root use vipw(8) to edit the passwd database, or otherwise

        # cap_mkdb /etc/master.passwd

       when the UID was changed?  It's the value in the hashed
       database cap_mkdb(1) builds that is used by the system.
       Updating that should have instantaneous effect.

   ii) You haven't said anything about what the source of your
       password data is, which probably means you're just using the
       flat file password database and not anything like NIS or LDAP.
       If you are using a distributed database, then a degree of
       latency while changes get propagated around the servers is to
       be expected.  However, that shouldn't take any more than a few
       minutes in a well configured system.

The problem is not with the ls(1) command per se.  It's the underlying
system library functions such as getpwuid(3) which do the translation
between numeric UIDs and usernames that are the seat of the problem.
You can see that by running some other command that uses getpwuid(3), eg:

    % perl -e 'print scalar getpwuid(503), "\n";'



Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP:         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the freebsd-questions mailing list