We are trying to set dos_attr c_time on files residing on a Windows XP Pro SP2 box. m_time works as expected but c_time doesn't even though both calls returns 0. We've attached a tcpdump containing output when: 1. Getting attributes 2. Set m_time 3. Getting attributes 4. Set c_time 5. Getting attributes The code was run from a FC4 box with IP 192.168.1.122. It connected to the Win client with IP 10.168.1.133 char *value1 = "2100000000"; char *value2 = "2000000000"; char *pBuffer2 = new char[1024]; smbc_getxattr( strPath.c_str(), "system.dos_attr.*", pBuffer2, 1024 ); smbc_setxattr( strPath.c_str(), "system.dos_attr.c_time", value1, strlen(value1), SMBC_XATTR_FLAG_REPLACE ); smbc_getxattr( strPath.c_str(), "system.dos_attr.*", pBuffer2, 1024 ); smbc_setxattr( strPath.c_str(), "system.dos_attr.m_time", value2, strlen(value2), SMBC_XATTR_FLAG_REPLACE ); smbc_getxattr( strPath.c_str(), "system.dos_attr.*", pBuffer2, 1024 ); Regards, Henrik
Created attachment 2094 [details] Tcpdump from the test
Ok, there are actually a couple of problems here. 1. Contrary to what many think (including me when I wrote much of this code), a POSIX c_time is NOT create time; it's "status change time". There's no way, using stat(2), to retrieve the create time. Since libsmbclient is intended to emulate POSIX requests, the use of c_time in libsmbclient should continue to be status change time, not create time. 2. Since c_time is supposed to be status change time, we should not be forcing it to never exceed the values of m_time and a_time. 3. There really should be a way, using the smbc_setxattr() function, to retrieve and set the create time (when the peer Windows version supports such a thing). This gives me a bunch of work to do in this area, so it may be a couple of weeks before I get to it. Please bug me if you haven't seen any progress by the end of August.
Hello Derrell, *ping* *ping* I was supposed to bug you at the end of august. :-) We did some further research and noticed that setting the m_time didn't work after all. We get really weird results. We also noticed that it is not very good to set m_times earlier c_times. =) Cheers, Henrik
> *ping* *ping* I was supposed to bug you at the end of august. :-) You're prompt. :-) I've scheduled time later this week to work on this. Jeremy did a bunch of work on time stuff last week, though, which may have solved some (all?) off the problems. He clarified in the code the meaning of c_time, changing some of the uses to change_time and others to create_time as appropriate, and fixed which field is sent where in the protocol. If you wouldn't mind testing the current version in svn and let me know the current state of working (or what's different than your original report), I'd appreciate it. Derrell
Hello Derrell, I've compiled the Version 3.0.23c-SVN-build-17927 and tried the test again. I can say that the result is now much more consistent. Setting m_time works as expected. Setting c_time doesn't work but at least doesn't change m_time anymore. :-) So the fixes Jeremy did sure did some wonders. Being able to set the m_time means a lot. The only thing still remains is being able to set the create_time. ;-) So, good luck and let me know if you need any more info/tests/debugs/beers. Cheers, Henrik
Hi again, I think I spoke a little too soon. Sure setting the attributes (at least m_time) works but know we get really weird results when getting the time. Using smbc_getxattr we sometimes get the a_time of the file into the m_time buffer and sometimes c_time and m_time are the same but on the client they are different. This is probably just a side effect of jeremy's changes but I wanted to let you know. Cheers, Henrik
This should be fixed with revision 18009. Retrieving all of the times, whether via smbc_stat() or smbc_getxattr() should now give the proper values of ACCESS TIME, WRITE TIME and status CHANGE TIME (a_time, m_time and c_time, respectively, in the structure returned by smbc_stat(), and additionally, CREATE TIME when using smbc_getxattr(). All four times can now be set using smbc_setxattr(). You'll need to turn on the new option "full_time_names" using smbc_option_set(). See examples/libsmbclient/testacl.c for how to do so. To set all four times, you can derive the usage from this testacl command line: tacl -f -S "system.*:CREATE_TIME:1000000000,ACCESS_TIME:1000000060,WRITE_TIME:1000000120,CHANGE_TIME:1000000180" 'smb://server/share/testfile.txt' Please let me know how things work for you. > So, good luck and let me know if you need any more info/tests/debugs/beers. I like a good strong ale. I'll pass on the American beers. :-)
We've run some test and all looks good! Great job! > (a_time, m_time and c_time, respectively, in the structure returned by I like that you now have c_time as change time everywhere and using a forth CREATE_TIME as option. Makes good consistency. > I like a good strong ale. I'll pass on the American beers. :-) Well, I'm from Sweden so we mostly drink vodka around here. Need that for the cold winters. Those American beers have never won my heart neither. :-)
One additional question. When running smbc_getxattr and smbc_setxattr against a Samba server I get values for create_time even though it is unsupported on my linux FS (ext3). Even though the CREATE_TIME values are not usable maybe it would be better to return 0 for CREATE_TIME when run against a Samba server just for clarity? Or I'm I missing something? :-) Here is a test ouput when ran against a ext3 FS: First run # ./acltest Get system.dos_attr.*, buffer: MODE:0x80,SIZE:448,CREATE_TIME:1135943291,ACCESS_TIME:1157249015,WRITE_TIME:1135943291,CHANGE_TIME:1135943291,INODE:0 Set smb://192.168.1.203/jonas/temp/Makefile2(system.dos_attr.*): CREATE_TIME:2000000000,WRITE_TIME:2100000000 Get system.dos_attr.*, buffer: MODE:0x80,SIZE:448,CREATE_TIME:1157249015,ACCESS_TIME:1157249015,WRITE_TIME:2100000000,CHANGE_TIME:2100000000,INODE:0 Second run # ./acltest Get system.dos_attr.*, buffer: MODE:0x80,SIZE:448,CREATE_TIME:1157249015,ACCESS_TIME:1157249015,WRITE_TIME:2100000000,CHANGE_TIME:2100000000,INODE:0 Set smb://192.168.1.203/jonas/temp/Makefile2(system.dos_attr.*): CREATE_TIME:2000000000,WRITE_TIME:2100000000 Get system.dos_attr.*, buffer: MODE:0x80,SIZE:448,CREATE_TIME:1157249015,ACCESS_TIME:1157249015,WRITE_TIME:2100000000,CHANGE_TIME:2100000000,INODE:0
> When running smbc_getxattr and smbc_setxattr against a Samba server I get > usable maybe it would be better to return 0 for CREATE_TIME when run against > a Samba server just for clarity? That would be a server issue, and the client library would have no way to know (on a smbc_getxattr()) whether the the create time is calculated or real. On a smbc_setxattr(), it's be possible to issue the "set" call and then do a "get" call to see if what was requested was actually set, but that's adding complexity and slowing things down for no good reason, I think. If you feel that the Samba server should be returning 0 for create time if the underlying file system doesn't support saving the create time, I'd suggest posting a new bug for that. The server dudes can then comment. Given your previous remarks, I'll mark this bug as Fixed. Thanks for the report and your testing! Derrell