rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Integer too small on AMD64 machine


From: Nick Bailey
Subject: Re: [rdiff-backup-users] Integer too small on AMD64 machine
Date: Tue, 12 Apr 2005 09:04:51 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1

Ben Escoto wrote:

   try: uname = pwd.getpwuid(uid)[0]

I haven't seen this before, perhaps someone else has some insight.
The problem seems to be that rdiff-backup can't query the username of
some uid because the uid (as read from the file system) is too big.

It seems it has indeed bitten some other people. Google found this for me:

   http://marc.free.net.ph/message/20050317.092005.79c1a132.en.html

Probably there is some file with a junk uid, but probably rdiff-backup
should handle this case without crashing.  Is it traditional that uids
have to be less than 65536/32768 or something?

I thought they could be up to 4294967294? That's what the above link implies. But I do seem to remember being told it was 65535 when I was an undergrad because UIDs were unsigned shorts (but that was in the 80s :)

Or should this be a bug in python's getpwuid since very large uids
should be allowable.
There are no silly entries in /etc/passwd, and the biggest uid/gid is 65534. Of course, there might be silly uids/gids on files, for example if someone did a tar xp or something. The users of the file server in this case are a bunch of Postgrads, all with root access to their local boxes, who just love stressing things (in a good way :)

I hacked in a print to find out the value of UID when that routine was called. I'm calling it via sudo and my uid is 1000 on that box. It was called first as 0, then 2001 (those are users of the fs). Then the stuff about filesystem capabilities gets printed, then it's called with 2000, 2002, and, bingo, with uid=4294967294.

That gets called from setdata_local, so let's print out the rpath.data dictionary (sorry, I know, I should learn how to use a debugger :)

{'uid': 4294967294, 'perms': 493, 'type': 'reg', 'ctime': 1097059287, 'devloc': 2065L, 'nlink': 1, 'gid': 4294967294, 'mtime': 1097059287, 'atime': 1097059287, 'inode': 22890417, 'size': 24620}
uid= 4294967294

Hmm.

address@hidden:/exports/home$ sudo ls -lnR | awk '$3>3000 {print $0}'
./niall/demos/4k-2004/src/sw/pirro - unnamed:
-rwxr-xr-x 1 4294967294 4294967294 4509 2005-03-18 11:38 config_basic_example -rw-r--r-- 1 4294967294 4294967294 20276 2005-03-18 11:38 config_basic_example.o
(approx 300 such examples).

So rdiff-backup comes out smelling of roses, with the slight caveat that it would have been nice if there were some indication of which files were causing the problems, or at least continued the backup so other users weren't penalised. The offending user will be ritually taunted and have his laboratory fridge rights temporarily revoked.

I guess he's been using Windoze, Apple, or some other strange architecture which has tar'd up a ball with uid=gid=-1, then this has been untar'd with the p flag or something like that. I hope this thread will be of some use to others coming across the same thing.

Niall, can I chmod your entire home directory to niall:niall? Is that OK? (think carefully before you answer...) Then we can all have incremental backups.

Nick/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]