McKee, Shawn wrote: > Could not fetch the entry for volume number 18446744072096448530 from VLDB > > I am assuming the "large" cloned volume ID is causing the problem as opposed > to an inability to create a cloned volume. I can make replicas on linat08 > for existing volumes without a problem. > > NOTE: The hex representations of the "cloned" volume from the move attempt > above and the 'vos examine': > > [linat08:local]# 2681864210 = 0x 9FDA0012 > [linat08:local]# 18446744072096448530 = 0x FFFFFFFF9FDA0012 > > Any suggestions? This seems like a 64 vs 32 bit issue.
Its a signed vs unsigned int problem. afsint.h and afscbint.h include typedef afs_uint32 VolumeId; which is used throughout the src/vol package for volume ids. In volser/vos.c and volser/vsprocs.c the volume id variables are defined as signed 32-bit (afs_int32). There are also some signed vs unsigned issued in some of the protocol structures. I believe the type VolumeId should be used consistently to define types of volume id variables. In vldbint.xg: struct [nu]vldbentry uses afs_uint32 for the volumeId array but afs_int32 for the cloneId. Same for VldbUpdateEntry. VldbListByAttributes uses afs_int32 for the volumeid. This is not a full examination but I believe it shows where the problem lies. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
