11.3 - SMB - file timestamps, bug?

arkoMax

Dabbler
Joined
Jul 13, 2017
Messages
16
Hello,

I came across an issue and don't know whether I made a mistake somewhere or if it's a bug.

I have a fresh installation of 11.3. I went through and setup my datasets (choosing share type SMB), permissions and SMB shares. No problem in accessing files. However, when copying data to the NAS, I noticed that file created timestamps were not syncing up (though folder created timestamps are fine). I use ROBOCOPY to preserve all timestamps to/from backups.

Interestingly, when using ROBOCOPY, all files get a created datetime of "Wednesday, ‎2 ‎January ‎1980, ‏‎10:00:00 AM", but when copying over via windows explorer, file created datetime equals whatever the modified datetime is. In any case, even with full permissions, attempting to change a file created timestamp (with something like NewFileTime) fails.

Digging through the settings a bit more, I found under share properties that VFS Object ixnas is active by default. Removing it fixes the above problem and I can again manipulate all timestamps. In the manual, for ixnas, it states that it is an experimental object to improve ACL compatibility with Windows. So is this a bug with ixnas? What is the impact of not having it active? @anodos stated that ixnas improves directory listing performance, so I would like to have it active but I cant not be able to change file timestamps.
Edit: please see post below after additional testing.

Is this a bug or have I made a mistake in configuration somewhere?
 
Last edited:

arkoMax

Dabbler
Joined
Jul 13, 2017
Messages
16
Thank you. Just a quick note, I didn't have this issue with my previous install 11.1-u7. Though I can't say at all what vfs settings were selected there.

Edit
---------------
I just did some more testing. My initial assessments as made in the first post are wrong. The following is what I found to actually be reproducible (irrespective of ixnas being selected or not):

Using either robocopy or an app like newfiletime, this applies to both files and folders:
  • Attempting to change just the created datetime (up or down), does not work
  • Changing the modified datetime (up or down) works without issue
  • The created datetime changes and gets set to the modified datetime IF it is less than the current created time, eg:
    • Current Created: 01/01/2000 Current Modified: 01/01/2000
    • change modified to 01/01/2001, created does not change
    • change modified to 01/01/1985, created changes to 01/01/1985
  • No way to change the created time upward
As mentioned, I did not have this issue on 11.1, and I rely quite often on manipulating timestamps.

Any help would be appreciated.
 
Last edited:

arkoMax

Dabbler
Joined
Jul 13, 2017
Messages
16
I have experimented a little bit more, and here is what I found out.

If you:
  • disable the VFS object ixnas from the SMB share properties, and
  • under services -> SMB -> properties, add "store dos attributes = yes" under the aux parameters,
then file/folder timestamps behave as I would expect them to, that is, they can be adjusted at will.
If I were to re-enable ixnas, the created datetime reverts back to "Wednesday, ‎2 ‎January ‎1980, ‏‎10:00:00 AM" and cannot be set to anything higher. Disabling it again, and the timestamp goes back to whatever I set it to (eg 2019). And exactly the same happens if store dos attributes is set to no and then yes again.

Is this a bug or by design?

I would like to have the freedom to adjust timestamps, but by default ixnas is enabled and the dos attributes parameter is not. Can someone knowledgable please tell me what the consequence to my system is in running these two settings as such if they are not recommended (ie default)? If there is a negative impact, is it reversible at a later time? I still haven't transferred back to the NAS the multiple terabytes of data as I don't know what the impact is and if I would have to redo it all over again.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,543
I have experimented a little bit more, and here is what I found out.

If you:
  • disable the VFS object ixnas from the SMB share properties, and
  • under services -> SMB -> properties, add "store dos attributes = yes" under the aux parameters,
then file/folder timestamps behave as I would expect them to, that is, they can be adjusted at will.
If I were to re-enable ixnas, the created datetime reverts back to "Wednesday, ‎2 ‎January ‎1980, ‏‎10:00:00 AM" and cannot be set to anything higher. Disabling it again, and the timestamp goes back to whatever I set it to (eg 2019). And exactly the same happens if store dos attributes is set to no and then yes again.

Is this a bug or by design?

I would like to have the freedom to adjust timestamps, but by default ixnas is enabled and the dos attributes parameter is not. Can someone knowledgable please tell me what the consequence to my system is in running these two settings as such if they are not recommended (ie default)? If there is a negative impact, is it reversible at a later time? I still haven't transferred back to the NAS the multiple terabytes of data as I don't know what the impact is and if I would have to redo it all over again.
Sorry forgot to reply here. I fixed the issue https://jira.ixsystems.com/browse/NAS-104949. Robocopy initially sets the timestamp to 01/01/1980. Changing VFS objects only masks the issue, it's still getting changed in the underlying FS. Looks like a bug upstream with regard to FreeBSD.
 

arkoMax

Dabbler
Joined
Jul 13, 2017
Messages
16
Alright, thanks. How should I proceed in the mean time, as I have yet to copy any data to the NAS?
Any detriment to disabling ixnas and "dos attributes = yes" for now, or better to wait for an update?
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,543
all right, thanks. How should I proceed in the mean time, as I have yet to copy any data to the NAS?
Any detriment to disabling ixnas and "dos attributes = yes" for now, or better to wait for an update?
"store DOS attributes" will mask the mtime / btime issue by writing the timestamps to an xattr. The issue will be unmasked once you re-enable ixnas. I will PM you a replacement binary.
 

seanm

Guru
Joined
Jun 11, 2018
Messages
570
Does this only happen with Robocopy or regular Window File Explorer too?
 

msim888

Cadet
Joined
Mar 4, 2020
Messages
9
It seems the timestamp issue isn't fixed in 11.3-U1
And it isn't only Robocopy related.
I've experienced the same thing with Windows File Explorer copy and move as well as Powershell Copy-Item and Move-Item commandlets.
 

msim888

Cadet
Joined
Mar 4, 2020
Messages
9
Even if I set the correct timestamp after the file copying or moving FreeNAS changes it in a few seconds again.
 

revengineer

Contributor
Joined
Oct 27, 2019
Messages
193
Is this still being worked? I am still having this issue with robocopy on FreeNAS 11.3-U3.2.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,543
Is this still being worked? I am still having this issue with robocopy on FreeNAS 11.3-U3.2.
Robocopy is setting timestamps to 1980? Try setting ixnas:dosattrib_xattr=true auxiliary parameter on the share. This will switch to storing dos attributes in xattrs rather than in file flags. We're probably not going to introduce the kernel change that's required to fix this functionality into 11.3.
 

revengineer

Contributor
Joined
Oct 27, 2019
Messages
193
@anodos Thanks for the tip, I solved this issue by using xcopy instead of robocopy. xcopy is not as fancy but sufficient for the incremental copy jobs on my media server. xcopy does preserve all dates during copy.

However, I will keep this in mind for the future. To confirm, the auxiliary parameter is to be entered on the share and not the samba service, correct?
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,543
@anodos Thanks for the tip, I solved this issue by using xcopy instead of robocopy. xcopy is not as fancy but sufficient for the incremental copy jobs on my media server. xcopy does preserve all dates during copy.

However, I will keep this in mind for the future. To confirm, the auxiliary parameter is to be entered on the share and not the samba service, correct?
You can change the parameter, and only the SMB share should be reloaded... but it changes the on-disk format for DOS metadata and timestamps without migrating them.
 
Top