Derrick Brashear wrote: > On Tue, Feb 24, 2009 at 4:58 AM, Anders Magnusson <ra...@ltu.se> wrote: > >> I took a quick look in the source code, and found that there are two >> interesting defines (in volser.h): >> >> #define VOLSER_MAXVOLNAME 65 >> #define VOLSER_OLDMAXVOLNAME 32 >> >> So, obviously someone has thought about allowing longer names, but the >> checks seems to be against >> the old name length so it don't work. >> What is needed if we want to use longer names? And may it cause >> incompatibility with clients >> or other cells or whatever? >> > > All vlserver calls already use 65: > const VL_MAXNAMELEN = 65; > So that means that the protocol (what is sent between the client and server) is already "65-byte-clean"?
> Sadly, look what's on the on-disk volume header: > typedef struct VolumeDiskData { > struct versionStamp stamp; /* Must be first field */ > VolumeId id; /* Volume id--unique over all systems */ > #define VNAMESIZE 32 /* including 0 byte */ > char name[VNAMESIZE]; /* Unofficial name for the volume */ > Hm, grepping shows that it is used in a bunch of structs. But besides VolumeDiskData , I assume all of them are only used inside the binaries...? > So basically, you'd have to upgrade that, including having an upgrade > and downgrade path for volume headers (and then switch out vos > anywhere you wanted to actually be able to manipulate the volumes) > So what you mean is basically this: - Change VNAMESIZE to 65 - Wrap VOLUMEINFOVERSION to 2 - Add compatibility code to where the struct is read from disk to convert it to new internal format. - Change all sanity checks for volume name length to new length. > It's not actually all that hard, realistically. > Probably not if there's knowledge of the internals :-) Biggest problem for me would be that I don't have any clues of the side effects of changes I might cause :-) -- Ragge _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info