I am facing some issue with smbc_getxattr() API. I am interested in "system.nt_sec_desc.owner_name+" attribute. The API usually works correctly as long as smbc_stat() is not invoked.. Once the code invokes smbc_stat() to get struct stat corresponding to the target files, subsequent invocations of smbc_getxattr(.., "system.nt_sec_desc.owner_name+", ..) gives incorrect results. On subsequent invocation, the call just returns SID (instead of user readable name). Is this a known issue??
I assume that you just had a typo in this bug report, and you intended to say "system.nt_sec_desc.owner+" not "system.nt_sec_desc.owner_name+". I am unable to reproduce this problem. I've modified examples/libsmbclient/testacl in v3-3-test branch to do what I believe you're saying. The command line for testacl would be something like this: ./testacl -R -g 'system.nt_sec_desc.owner+' 'smb://myserver/c%24/boot.ini' The -g <acl> flag is to GET the specified acl, and the -R flag is to RETRY getting the specified acl again after issuing an smbc_stat() call on the specified file. Please test with this application and let me know if you encounter the same problem. If not, I suspect that something in your application is scribbling on memory. Cheers, Derrell
Created attachment 3328 [details] Test "c" code CLI: ./test <remote_file_name>
Created attachment 3329 [details] The debug output.
Thanks for your comments Darrell. Yes, I intended to say "system.nt_sec_desc.owner+". I will run the test benchmark code to reproduce the issue as you suggested. Meanwhile here is a sample test code that is giving problem on my setup (kindly ignore the code sanity). You may give it a try too. It takes the remote file name as an input argument. I am calling smbc_stat() multiple times between two invocations of smbc_getxattr().
Your application works fine for me. I wonder if you have a compilation consistency problem. The size of struct stat differs depending upon compile-time options. It's possible that libsmbclient is scribbling on your memory or your app is scribbling on libsmbclient's memory if they don't both use the same structure sizes. Are you compiling your own libsmbclient library? If so you can do this test: Save your test program in examples/libsmbclient as x.c and patch the Makefile like this: ====================================================================== diff --git a/examples/libsmbclient/Makefile b/examples/libsmbclient/Makefile index 7415f4f..81500b5 100644 --- a/examples/libsmbclient/Makefile +++ b/examples/libsmbclient/Makefile @@ -94,6 +94,10 @@ testwrite: testwrite.o @echo Linking testwrite $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBSMBCLIENT) -lpopt +x: x.o + @echo Linking x + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBSMBCLIENT) -lpopt + smbsh: make -C smbwrapper ====================================================================== Now, try running "./x <path>" and confirm that it works as expected. I believe it will. You can then look at the compile options used to compile x.c so you know what options you must use for your real app. If you're using a pre-compiled libsmbclient library, you'll need to find out what options it was built with. (Inconsistency between how the library is built and how the application is compiled is an ongoing problem that I really want to come up with a descent solution for.) Derrell
No reply for six months. Please re-open if necessary. Derrell