on solaris writing extended attributes causes mtime update. That means with "store dos attributes = yes" on Solaris almost all files will get the current time as last modify time when being accessed. Very bad thing. Is is feasible we check before and restore the mtime after changing EAs then?
That's ugly, and causes extra meta-data updates we really don't want to do in general code paths. Can we hide this inside the Solaris-specific EA code ? Jeremy.
I cannot reproduce your problem. I've confirmed the following scenario on Solaris 10 10/06 (Update 3 + some patches) with UFS and Solaris 10 9/10 (Update 9 + some patches) with ZFS. $ uname -a SunOS fmys-s10 5.10 Generic_142910-17 i86pc i386 i86pc $ date Mon Mar 26 05:08:37 JST 2012 $ touch file.txt $ ls -l file.txt -rw-r--r-- 1 fmys fmys 0 Mar 26 05:08 file.txt $ runat file.txt mkfile 123 xattr.xxx $ ls -l file.txt -rw-r--r-- 1 fmys fmys 0 Mar 26 05:08 file.txt $ runat file.txt ls -l total 1 -rw------T 1 fmys fmys 123 Mar 26 05:09 xattr.xxx
Fixed. Sorry... $ date Mon Mar 26 05:14:32 JST 2012 $ touch -r /etc/passwd file.txt $ ls -l file.txt -rw-r--r-- 1 root root 0 Jun 7 2011 file.txt $ runat file.txt mkfile 123 xattr.xxx $ ls -l file.txt -rw-r--r-- 1 root root 0 Jun 7 2011 file.txt $ runat file.txt ls -l total 1 -rw------T 1 root root 123 Mar 26 05:14 xattr.xxx
a customer had that problem on a Solaris 10 system with UFS. I currently don't have such a system availbale for testing. But thanks for your testing, in case it was broken this way it seems to have been fixed. So I guess you also don't have any issues when setting "store dos attributes = yes" on your setup?
I've confirmed that file mtime is NOT updated when the extended attribute "user.DOSATTRIB" is updated from Windows 7 via smbd. My smb.conf have "store dos attributes = yes" and the client user have write privilege to xattr.
confirmed.