Opened 16 years ago
Last modified 16 years ago
#267 assigned defect
UIDs / GIDs not enough bits
| Reported by: | jwhit424 | Owned by: | Bruno Cornec |
|---|---|---|---|
| Priority: | normal | Milestone: | 4.0.0 |
| Component: | mondo | Version: | 2.2.5 |
| Severity: | normal | Keywords: | |
| Cc: |
Description
user with uid 98765 becomes user 33229 after mondo restore.
98765 - 33229 = 65536. Integer Overflow.
This is on RedHat 5 (32 bit) on VMware ESX 3.0.2. with mindi 2.0.1.
Attachments (2)
Change History (6)
comment:1 by , 16 years ago
by , 16 years ago
| Attachment: | mondoarchive.log.gz added |
|---|
by , 16 years ago
| Attachment: | mondorestore.log.gz added |
|---|
comment:2 by , 16 years ago
Seems strange to me, too. The passwd file actually didn't change, but all of the uids stored in the i-nodes did.
comment:3 by , 16 years ago
| Status: | new → assigned |
|---|
Ah ok. So it's more a problem with afio I guess, which may not support 64bits ids. Will have a look
comment:4 by , 16 years ago
I've seen this same problem before on 64-bit machines I've worked on. I didn't know what was causing it, though. That's the one thing I found that kept me from using it, because my boss didn't like that it seemed to be intermittently working. I'll have to see if our 32-bit machines are unaffected.
Note:
See TracTickets
for help on using tickets.
Cold you provide me the /var/log/mondorestore.log file at restore time please ? from the top of y head, I don't see where MondoRescue is modifying the passwd file (and why it should), so I don't really understand why this is happening. lso the /var/log/monoarchive.log would be nice as well. TIA.