search for: listxattr

Move in an own function the code that does the (l)listxattrs allocating the buffer of the right legth, as it will be useful later. No functional changes, just code motion. --- daemon/xattr.c | 64 ++++++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 44 insertions(+), 20 deletions(-) diff --git a/daemon/xattr.c b/daemon/xattr.c index...

...itely want to > copy them! Right, fixed to be part of the permissions (or mode actually, see below). > > + ssize_t len, vlen, ret; > > + CLEANUP_FREE char *buf = NULL, *attrval = NULL; > > + size_t i, attrval_len = 0; > > + > > + CHROOT_IN; > > + len = listxattr (src, NULL, 0); > > + CHROOT_OUT; > > + if (len == -1) { > > + reply_with_perror ("listxattr: %s", src); > > + goto error; > > + } > > + > > + buf = malloc (len); > > + if (buf == NULL) { > > + reply_with_perror ("ma...

....org/wiki/MinGW http://www.annexia.org/fedora_mingw -------------- next part -------------- >From e48d2ab05b85c02f76da09afe1ff5027a750cea1 Mon Sep 17 00:00:00 2001 From: Richard W.M. Jones <rjones at redhat.com> Date: Mon, 28 Mar 2011 14:45:23 +0100 Subject: [PATCH 2/2] fuse: Fix getxattr, listxattr calls and add a regression test. The documentation for the getxattr and listxattr calls is not very clear and as a result we were always returning something different from that which the Linux kernel would usually return. This fixes these calls, at least far enough that both the 'getfattr'...

...ity information is either unavailable or can't be displayed' - which would make sense given the error message in the subject line. Are ACLs stored anywhere else, that I could view? I have found a sample C program here, which I might compile and try... : http://man7.org/linux/man-pages/man2/listxattr.2.html FWIW, the sysvol entry in my smb.conf looks like this: [sysvol] path = /usr/local/samba/var/locks/sysvol read only = No acl_xattr:ignore system acls = yes Any tips on anything else I could investigate? I can work around this reasonably reliably via the steps above;...

...stat("stroth/testfiles_10000-50000/10000/03915", {st_mode=S_IFREG|0660, st_size=1265, ...}) = 0 <0.000312> getxattr("stroth/testfiles_10000-50000/10000/03915", "user.org.netatalk.Metadata", 0x55803d5c9a90, 402) = -1 ENODATA (No data available) <0.000348> listxattr("testfiles_10000-50000/10000/03915", "", 1024) = 0 <0.000345> a trace of the same directory listing with vfs_fruit disabled is faster and doesn't show the getxattr call: newfstatat(36, "03239", {st_mode=S_IFREG|0660, st_size=303, ...}, AT_SYMLINK_NOFOLLOW...

...------------------------------------------ 1 file changed, 11 insertions(+), 43 deletions(-) diff --git a/daemon/xattr.c b/daemon/xattr.c index abed5ff..d8ad59a 100644 --- a/daemon/xattr.c +++ b/daemon/xattr.c @@ -55,6 +55,7 @@ static guestfs_int_xattr_list *getxattrs (const char *path, ssize_t (*listxattr) static int _setxattr (const char *xattr, const char *val, int vallen, const char *path, int (*setxattr) (const char *path, const char *name, const void *value, size_t size, int flags)); static int _removexattr (const char *xattr, const char *path, int (*removexattr) (const char *path, const char...

On Fri, 27 Apr 2018 22:40:41 +0100 Jonathan Hunter via samba <samba at lists.samba.org> wrote: > OK - some more detail I have found in the meantime. > > I have compiled & ran listxattr, and I can now see a difference > between a working and a broken file: > > me at dc2:~/download $ > sudo ./listxattr /usr/local/samba/var/locks/sysvol/ > mydomain.org/brokenfile.txt user.DOSATTRIB: 0x20 > system.posix_acl_access: > > me at dc2:~/download $ > sudo ./list...

OK - some more detail I have found in the meantime. I have compiled & ran listxattr, and I can now see a difference between a working and a broken file: me at dc2:~/download $ sudo ./listxattr /usr/local/samba/var/locks/sysvol/ mydomain.org/brokenfile.txt user.DOSATTRIB: 0x20 system.posix_acl_access: me at dc2:~/download $ sudo ./listxattr /usr/local/samba/var/locks/sysvol/ mydo...

Hey everyone, after we finished the introduction of the new posix acl api last cycle we still left the generic POSIX ACL xattr handler around for two reasons. First, because a few filesystems relied on the ->list() method of the generic POSIX ACL xattr handlers in their ->listxattr() inode operation. Second, during inode initalization in inode_init_always() the registered xattr handlers in sb->s_xattr are used to raise IOP_XATTR in inode->i_opflags. With the removal of the legacy POSIX ACL handlers it is at least possible for a filesystem to only implement POSIX ACLs b...

...100644 > --- a/daemon/xattr.c > +++ b/daemon/xattr.c > @@ -545,8 +545,98 @@ do_lgetxattr (const char *path, const char *name, size_t *size_r) > return buf; /* caller frees */ > } > > +int > +copy_xattrs (const char *src, const char *dest) > +{ > +#if defined(HAVE_LISTXATTR) && defined(HAVE_GETXATTR) && defined(HAVE_SETXATTR) I wonder if there are any platforms that lack one of listxattr, getxattr and setxattr, but at the same time have one of these calls. The xattr code (in general) is incredibly complex because of all these tests. I guess Mac OS X...

...00/10000/03915", > {st_mode=S_IFREG|0660, > st_size=1265, ...}) = 0 <0.000312> > getxattr("stroth/testfiles_10000-50000/10000/03915", > "user.org.netatalk.Metadata", 0x55803d5c9a90, 402) = -1 > ENODATA (No data > available) <0.000348> > listxattr("testfiles_10000-50000/10000/03915", "", 1024) = 0 > <0.000345> > > a trace of the same directory listing with vfs_fruit disabled > is faster > and doesn't show the getxattr call: > > newfstatat(36, "03239", {st_mode=S_IFREG|0660, st...

...78 insertions(+), 48 deletions(-) diff --git a/daemon/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 str...

...75 insertions(+), 48 deletions(-) diff --git a/daemon/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 conta...

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

On Wed, Dec 12, 2018 at 04:37:43PM +0100, Ralph Böhme via samba wrote: >On Wed, Dec 12, 2018 at 03:35:00PM +0100, Stephan Roth via samba wrote: >>My goal with activating vfs_fruit was to speed up directory listings >>for Mac clients, which works. Can the accompanying slowdown for >>Windows clients be avoided? > >yeah, I guess so, but somebody has to dig through the

On Mon, Jan 30, 2023 at 10:10:52AM +0100, Christian Brauner wrote: > However, a few filesystems still rely on the ->list() method of the > generix POSIX ACL xattr handlers in their ->listxattr() inode operation. > This is a very limited set of filesystems. For most of them there is no > dependence on the generic POSIX ACL xattr handler in any way. > > In addition, during inode initalization in inode_init_always() the > registered xattr handlers in sb->s_xattr are used...

Hi, I've been using rsync (OSX Tiger now Leopard) to backup my home folder daily using -a -H -A -X link-dest=dir to make incremental backups. There was a problem though since many files especially images, movies etc would be recopied each time instead of creating hard links. I have been testing the pre5 release and found that it seems to make hard links correctly for all files. I

...hing I did was something like this cd /mnt/btrfs-test for i in $(seq 0 100000); do touch file_$i; done and then run time ./xattr-test /mnt/btrfs 0 time ./xattr-test /mnt/btrfs 1 time ./xattr-test /mnt/btrfs 2 the 0 test creates 100 xattrs for every file in the directory. the 1 test just does a listxattr for every file in the directory, which is enough to read in all the xattrs. The last test deletes all of the xattrs individually for each file. For testing with no cache just unmount between each of these tests. Thanks much, Josef #include <sys/types.h> #include <sys/stat.h> #inclu...

...lib/system.c lib/system.c: In function 'sys_getxattr': lib/system.c:1420: error: too few arguments to function 'getxattr' lib/system.c: In function 'sys_fgetxattr': lib/system.c:1504: error: too few arguments to function 'fgetxattr' lib/system.c: In function 'sys_listxattr': lib/system.c:1705: error: too few arguments to function 'listxattr' lib/system.c: In function 'sys_flistxattr': lib/system.c:1741: error: too few arguments to function 'flistxattr' lib/system.c: In function 'sys_removexattr': lib/system.c:1759: error: too few a...

Currently, when listing xattrs, kernel define XATTR_LIST_MAX as 65536 in include/linux/limits.h, so it can't handle too many xattrs. But with ocfs2 xattr tree, we actually have no limit for the number. And it will pollute the message with something like this when listing. (27738,0):ocfs2_iterate_xattr_buckets:3158 ERROR: status = -34 (27738,0):ocfs2_xattr_tree_list_index_block:3264 ERROR: