Re: [libvirt] [PATCH 4/4] storage: fix uid_t|gid_t handling on 32 bit Linux

2013-02-26 Thread Sebastian Wiedenroth
Hi, Am 26.02.2013 um 13:06 schrieb Philipp Hahn : > @Sebastian: Is (uid_t)-1 = (u32)-1 special for Sheepdog or was the file just > created by a previous virsh-dump, which outputs UINT_MAX instead of -1? The sheepdog backend doesn't care about uid/gid. I probably created the file using virsh-du

Re: [libvirt] [PATCH 4/4] storage: fix uid_t|gid_t handling on 32 bit Linux

2013-02-26 Thread Philipp Hahn
Hello, Am Montag 25 Februar 2013, 15:58:50 schrieb Michal Privoznik: > On 22.02.2013 17:55, Philipp Hahn wrote: > > uid_t and gid_t are opaque types, ranging from s32 to u32 to u64. ... > This one breaks storagevolxml2xmltest: > TEST: storagevolxml2xmltest ... > ... OK 7) Storage Vol XML-2-XML

Re: [libvirt] [PATCH 4/4] storage: fix uid_t|gid_t handling on 32 bit Linux

2013-02-25 Thread Eric Blake
On 02/22/2013 09:55 AM, Philipp Hahn wrote: > uid_t and gid_t are opaque types, ranging from s32 to u32 to u64. > > Unfortunately libvirt uses the value -1 to mean "current process", which > on Linux32 gets converted to ALLONE := +(2^32-1) = 4294967295. I like the standardized name INT_MAX better

Re: [libvirt] [PATCH 4/4] storage: fix uid_t|gid_t handling on 32 bit Linux

2013-02-25 Thread Michal Privoznik
On 22.02.2013 17:55, Philipp Hahn wrote: > uid_t and gid_t are opaque types, ranging from s32 to u32 to u64. > > Unfortunately libvirt uses the value -1 to mean "current process", which > on Linux32 gets converted to ALLONE := +(2^32-1) = 4294967295. > > Different libvirt versions used different

[libvirt] [PATCH 4/4] storage: fix uid_t|gid_t handling on 32 bit Linux

2013-02-22 Thread Philipp Hahn
uid_t and gid_t are opaque types, ranging from s32 to u32 to u64. Unfortunately libvirt uses the value -1 to mean "current process", which on Linux32 gets converted to ALLONE := +(2^32-1) = 4294967295. Different libvirt versions used different formatting in the past, which break one or the other