This a summary to an old problem I posted at least several months back.
I just now finally got around to figuring it out. Here is my original
post.
> I'm having a small problem, or should I say annoyance, with a product
> kit I'm building. When I install the kit using setld, tar spits out
> errors saying it was unable to preserve owner/group. However, since
> setld was run as root it actually DOES preserve the owner/group. setld
> then continues on to say that the kit may not have been installed
> correctly. This may be very misleading to the customer, and we would
> have to include something in our installation manuals telling them
> to ignore these errors. I could give all my files root ownership, and
> then change ownership after installation, but I would like to avoid this.
> Does anyone know of another way to avoid this? Or does anyone know of
> something I could be doing wrong?
It seems the error messages I describe above are caused by a bogus
user id owning files in the tar file (the user id is actually negative).
I traced it back and it seems the bogus user id is caused by the tar
command that creates the archive when the kit is created. In my case,
some files in my kit are owned by a user id that does not have a real
user on my system (when you do an "ls -l" the file's owner is just a
number, not a user name). When the kits command calls tar to create
the archive the tar file that is created does not have the user id
preserved. It is a negative number, obviously invalid. I guess I 've
found a problem with tar? Has anyone ever seen this before? The
strange thing is that the tar file that is created doesn't always seem
to have bogus number for the owner's user id. For some kits I create
it works, for some it doesn't, although it is consistent from kit to
kit. That is, if one kit ends up with bogus user id's in its tar file
it does it every time, if one kit does not end up with bogus user id's
it never does. So I guess there must be some subtle difference
among my kits that I'm not seeing.
In any case, the way I solved my problem was to create a user in
/etc/passwd that corresponds to the user id that owns the files I'm
kitting.
Regards,
Mike
----------------------------------------------------------------------
Michael Galuza
DeJarnette Research Systems mgaluza_at_dejarnette.com
401 Washington Ave Suite 700 Voice: +1(410)583-0680 x691
Towson, MD 21204 Fax: +1(410)583-0696
----------------------------------------------------------------------
Received on Mon Feb 10 1997 - 22:48:44 NZDT