From: Hans B. <han...@gm...> - 2013-07-29 09:12:45
|
Hi. I have implemented the xattr set of call-backs but experience very strange behavior from getfattr. If I use the 'attr -l' or 'attr -g' command everything works as expected. But when trying to list some extended attributes using getfattr all I get is rubbish :( From 'getfattr test_file': # file: test_file user.test_foo=0sMTIzAA== user.test_fee=0sMTIzAA== From 'attr -l test_file': Attribute "test_foo" has a 4 byte value for test_file Attribute "test_fee" has a 4 byte value for test_file From 'attr -g test_foo test_file': Attribute "test_foo" had a 4 byte value for test_file: 123 The values are all 'fake' and hardcoded to return "123\0" in getxattr() with a size of 4. What possibly could I have made wrong here? I would have expected output similar to this from getfattr: # file: test_file user.test_foo=123 user.test_fee=123 Hans --- FUSE library version: 2.8.6 fusermount version: 2.8.6 using FUSE kernel interface version 7.12 |
From: Hans B. <han...@gm...> - 2013-07-29 09:17:25
|
On 2013-07-29 11:12, Hans Beckerus wrote: > Hi. I have implemented the xattr set of call-backs but experience very > strange behavior from getfattr. > If I use the 'attr -l' or 'attr -g' command everything works as expected. > But when trying to list some extended attributes using getfattr all I > get is rubbish :( > > From 'getfattr test_file': > # file: test_file > user.test_foo=0sMTIzAA== > user.test_fee=0sMTIzAA== > > From 'attr -l test_file': > Attribute "test_foo" has a 4 byte value for test_file > Attribute "test_fee" has a 4 byte value for test_file > > From 'attr -g test_foo test_file': > Attribute "test_foo" had a 4 byte value for test_file: > 123 > > The values are all 'fake' and hardcoded to return "123\0" in > getxattr() with a size of 4. > What possibly could I have made wrong here? I would have expected > output similar to this from getfattr: > > # file: test_file > user.test_foo=123 > user.test_fee=123 > > Hans > > --- > FUSE library version: 2.8.6 > fusermount version: 2.8.6 > using FUSE kernel interface version 7.12 > > Sorry. Was to a bit quick on the send button. Just discovered that you need to tell getfattr what encoding to use. In this case '-e text'. But can fuse actually handle anything but text? The value is supposed to be sent to a char array? Hans |
From: Jean-Pierre <jea...@wa...> - 2013-07-29 09:22:54
|
Hans Beckerus wrote: > Hi. I have implemented the xattr set of call-backs but experience very > strange behavior from getfattr. > If I use the 'attr -l' or 'attr -g' command everything works as expected. > But when trying to list some extended attributes using getfattr all I > get is rubbish :( > > From 'getfattr test_file': > # file: test_file > user.test_foo=0sMTIzAA== > user.test_fee=0sMTIzAA== MTIzAA== is the base64 encoding of "123\0", the final null character prevents getfattr from outputting the value as plain text. Jean-Pierre |
From: Hans B. <han...@gm...> - 2013-07-29 09:41:53
|
On 2013-07-29 11:22, Jean-Pierre wrote: > Hans Beckerus wrote: >> Hi. I have implemented the xattr set of call-backs but experience very >> strange behavior from getfattr. >> If I use the 'attr -l' or 'attr -g' command everything works as expected. >> But when trying to list some extended attributes using getfattr all I >> get is rubbish :( >> >> From 'getfattr test_file': >> # file: test_file >> user.test_foo=0sMTIzAA== >> user.test_fee=0sMTIzAA== > MTIzAA== is the base64 encoding of "123\0", the final null > character prevents getfattr from outputting the value as > plain text. > > Jean-Pierre Thanks. In the case of a 2-byte value (eg. 0xffff). Is it then enough to say size 2 in getxattr() or should I always make sure it is 0-terminated and instead say size 3? Or is that going to confuse getfattr? Hans > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel > > |
From: Jean-Pierre <jea...@wa...> - 2013-07-29 10:07:53
|
Hans Beckerus wrote: > On 2013-07-29 11:22, Jean-Pierre wrote: >> Hans Beckerus wrote: >>> Hi. I have implemented the xattr set of call-backs but experience very >>> strange behavior from getfattr. >>> If I use the 'attr -l' or 'attr -g' command everything works as expected. >>> But when trying to list some extended attributes using getfattr all I >>> get is rubbish :( >>> >>> From 'getfattr test_file': >>> # file: test_file >>> user.test_foo=0sMTIzAA== >>> user.test_fee=0sMTIzAA== >> MTIzAA== is the base64 encoding of "123\0", the final null >> character prevents getfattr from outputting the value as >> plain text. >> >> Jean-Pierre > Thanks. In the case of a 2-byte value (eg. 0xffff). Is it then enough to > say size 2 in getxattr() or should I always make sure it is 0-terminated > and instead say size 3? Or is that going to confuse getfattr? > An extended attribute is any ordered sequence of bytes. It is not necessarily printable, and its size is stored apart. The byte order may be a problem for binary values on pluggable file systems which may be mounted on both big endian and little endian computers. Jean-Pierre |
From: Hans B. <han...@gm...> - 2013-07-29 10:37:17
|
On 2013-07-29 12:07, Jean-Pierre wrote: > Hans Beckerus wrote: >> On 2013-07-29 11:22, Jean-Pierre wrote: >>> Hans Beckerus wrote: >>>> Hi. I have implemented the xattr set of call-backs but experience very >>>> strange behavior from getfattr. >>>> If I use the 'attr -l' or 'attr -g' command everything works as expected. >>>> But when trying to list some extended attributes using getfattr all I >>>> get is rubbish :( >>>> >>>> From 'getfattr test_file': >>>> # file: test_file >>>> user.test_foo=0sMTIzAA== >>>> user.test_fee=0sMTIzAA== >>> MTIzAA== is the base64 encoding of "123\0", the final null >>> character prevents getfattr from outputting the value as >>> plain text. >>> >>> Jean-Pierre >> Thanks. In the case of a 2-byte value (eg. 0xffff). Is it then enough to >> say size 2 in getxattr() or should I always make sure it is 0-terminated >> and instead say size 3? Or is that going to confuse getfattr? >> > An extended attribute is any ordered sequence of bytes. > It is not necessarily printable, and its size is stored > apart. > > The byte order may be a problem for binary values on > pluggable file systems which may be mounted on both > big endian and little endian computers. > > Jean-Pierre > Yes. I realize that endianess might cause issues here :( Maybe the only "safe" way to make such code work seamlessly across different systems is to define all values as "text" based. Hans > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel > > |