search for: 0bar

...mon/xattr.c b/daemon/xattr.c index 5c9f064ce..482df9af0 100644 --- a/daemon/xattr.c +++ b/daemon/xattr.c @@ -89,6 +89,35 @@ do_lremovexattr (const char *xattr, const char *path) return _removexattr (xattr, path, lremovexattr); } +/** + * L<listxattr(2)> returns the string C<"foo\0bar\0baz"> of length + * C<len>. (The last string in the list is \0-terminated but the \0 + * is not included in C<len>). + * + * This function splits it into a regular list of strings. + * + * Note the caller must free the returned string list. + */ +static char ** +split_attr_nam...

...mon/xattr.c b/daemon/xattr.c index 5c9f064ce..761f6074b 100644 --- a/daemon/xattr.c +++ b/daemon/xattr.c @@ -89,6 +89,32 @@ do_lremovexattr (const char *xattr, const char *path) return _removexattr (xattr, path, lremovexattr); } +/** + * L<listxattr(2)> returns the string C<"foo\0bar\0baz"> of length + * C<len>. (The last string in the list is \0-terminated but the \0 + * is not included in C<len>). + * + * This function splits it into a regular list of strings. + * + * B<Note> that the returned list contains pointers to the original + * strings in C&...

..._BLOCK> <VERSION op0=2> <COMDAT op0=0 ...> ; name = foo <FUNCTION op0=0 ...> ; name = foo <GLOBALVAR op0=4 ...> ; name = bar <ALIAS op0=8 ...> ; name = baz ; function bodies, etc. </MODULE_BLOCK> <STRTAB_BLOCK> <STRTAB_BLOB blob="foo\0bar\0baz\0"> </STRTAB_BLOCK> Each STRTAB_BLOCK would apply to all preceding MODULE_BLOCKs. This means that bitcode files can continue to be concatenated with "llvm-cat -b". (Normally bitcode files would contain a single string table, which in multi-module bitcode files would be...

v1 here: https://www.redhat.com/archives/libguestfs/2020-March/msg00099.html This one fixes most of the points picked up in review, and does not strdup the strings which should keep down memory usage if that is a concern. Rich.

...<COMDAT op0=0 ...> ; name = foo > <FUNCTION op0=0 ...> ; name = foo > <GLOBALVAR op0=4 ...> ; name = bar > <ALIAS op0=8 ...> ; name = baz > ; function bodies, etc. > </MODULE_BLOCK> > <STRTAB_BLOCK> > <STRTAB_BLOB blob="foo\0bar\0baz\0"> > </STRTAB_BLOCK> > > > Why is the string table after the module instead of before? > > > Each STRTAB_BLOCK would apply to all preceding MODULE_BLOCKs. This means > that bitcode files can continue to be concatenated with "llvm-cat -b". > &...

...<COMDAT op0=0 ...> ; name = foo > <FUNCTION op0=0 ...> ; name = foo > <GLOBALVAR op0=4 ...> ; name = bar > <ALIAS op0=8 ...> ; name = baz > ; function bodies, etc. > </MODULE_BLOCK> > <STRTAB_BLOCK> > <STRTAB_BLOB blob="foo\0bar\0baz\0"> > </STRTAB_BLOCK> > > > Why is the string table after the module instead of before? > For implementation simplicity. The idea is that the BitcodeWriter would have a member of type StringTableBuilder which would accumulate strings while writing the bitcode modu...

https://bugzilla.redhat.com/show_bug.cgi?id=1811539 Commands including virt-diff which read extended attributes will sometimes fail on NTFS filesystems that are using system compressed. The reason is complex, see comment 5 of the bug linked above. This patch filters out the troublesome xattr. For justification, see the comment I added in patch 3. Patch 1 & 2 are refactoring. I was on the

...name = foo >> <FUNCTION op0=0 ...> ; name = foo >> <GLOBALVAR op0=4 ...> ; name = bar >> <ALIAS op0=8 ...> ; name = baz >> ; function bodies, etc. >> </MODULE_BLOCK> >> <STRTAB_BLOCK> >> <STRTAB_BLOB blob="foo\0bar\0baz\0"> >> </STRTAB_BLOCK> >> >> >> Why is the string table after the module instead of before? >> > > For implementation simplicity. The idea is that the BitcodeWriter would > have a member of type StringTableBuilder which would accumulate stri...

Hi, attached there is a prototype of patch for adding a new copy-attributes command. Such command would allow copy the attributes of a "file" to another, so for example in guestfish: copy-attributes foo bar permissions:true xattributes:false would only copy the permissions of foo to bar, not copying its extended attributes too. Just few notes: - my first daemon command, so

...len, vlen, ret, attrval_len = 0; + CLEANUP_FREE char *buf = NULL, *attrval = NULL; + size_t i; + + buf = _listxattrs (src, listxattr, &len); + if (buf == NULL) + /* _listxattrs issues reply_with_perror already. */ + goto error; + + /* What we get from the kernel is a string "foo\0bar\0baz" of length + * len. + */ + for (i = 0; i < (size_t) len; i += strlen (&buf[i]) + 1) { + CHROOT_IN; + vlen = getxattr (src, &buf[i], NULL, 0); + CHROOT_OUT; + if (vlen == -1) { + reply_with_perror ("getxattr: %s, %s", src, &buf[i]); + got...

...goto error; > + } > + > + CHROOT_IN; > + len = listxattr (src, buf, len); > + CHROOT_OUT; > + if (len == -1) { > + reply_with_perror ("listxattr: %s", src); > + goto error; > + } > + > + /* What we get from the kernel is a string "foo\0bar\0baz" of length > + * len. > + */ > + for (i = 0; i < (size_t) len; i += strlen (&buf[i]) + 1) { > + CHROOT_IN; > + vlen = getxattr (src, &buf[i], NULL, 0); > + CHROOT_OUT; > + if (vlen == -1) { > + reply_with_perror ("getxattr: %s,...

...len == -1) { > > + reply_with_perror ("listxattr: %s", src); > > + goto error; > > + } This two-pass snippet to do (l)listxattr is already elsewhere in xattr.c, I will move it to an own function. > > + /* What we get from the kernel is a string "foo\0bar\0baz" of > > length + * len. > > + */ > > + for (i = 0; i < (size_t) len; i += strlen (&buf[i]) + 1) { > > + CHROOT_IN; > > + vlen = getxattr (src, &buf[i], NULL, 0); > > + CHROOT_OUT; > > + if (vlen == -1) { > > +...

...name = foo >> <FUNCTION op0=0 ...> ; name = foo >> <GLOBALVAR op0=4 ...> ; name = bar >> <ALIAS op0=8 ...> ; name = baz >> ; function bodies, etc. >> </MODULE_BLOCK> >> <STRTAB_BLOCK> >> <STRTAB_BLOB blob="foo\0bar\0baz\0"> >> </STRTAB_BLOCK> >> >> >> Why is the string table after the module instead of before? >> > > For implementation simplicity. The idea is that the BitcodeWriter would > have a member of type StringTableBuilder which would accumulate stri...