Issue with "Modified" timestamps on Windows file copy

[nharrington]

If you feel enterprising, you can extract the attached zipped file, clone your boot environment, and replace /usr/local/lib/shared-modules/vfs/zfsacl.so with it. Once you do this run the command "service smbd onerestart".

Thanks for the quick response, anodos. I'm afraid I'm not having the same luck as LarryG. I followed your instructions, but I'm still seeing the modified dates on copied files being set to the date/time that the copy occurred:

Code:

Cloned boot environment from 11.3-U1 then restarted FreeNAS:
root@nas01:/ # mount | grep boot
freenas-boot/ROOT/11.3-U1-ModifiedDateFix on / (zfs, local, noatime, nfsv4acls)

Copied replacement file into position:
root@nas01:/usr/local/lib/shared-modules/vfs # ll zfsacl*
-rwxr-xr-x  1 root  wheel  107149 Mar  1 20:02 zfsacl.so*

Restarted SMBD:
root@nas01:/usr/local/lib/shared-modules/vfs # service smbd onerestart
Stopping smbd.
Waiting for PIDS: 2198.
Starting smbd.

Created temporary directory on SMB share (O:\0)
Created directories on O:\0 for COPY, XCOPY, ROBOCOPY, and Windows Explorer
Used each method to copy a file from C: to O:\0\...

Source:
 Directory of C:\Utility
02/25/2020  11:43 AM             2,236 MapDrives.cmd


Destinations:
 Directory of O:\0\copy
03/01/2020  08:40 PM             2,236 MapDrives.cmd

 Directory of O:\0\explorer
03/01/2020  08:41 PM             2,236 MapDrives.cmd

 Directory of O:\0\robocopy
02/25/2020  11:43 AM             2,236 MapDrives.cmd

 Directory of O:\0\xcopy
03/01/2020  08:40 PM             2,236 MapDrives.cmd

As you can see, ROBOCOPY is still the only method that is preserving the modified timestamp.

Out of curiousity, I also tried restarting FreeNAS after the test above, but the results were the same.

I noticed that the file that was modified was zfsacl.so, however I'm just using the default 11.3-RELEASE vfs objects plus fruit (i.e., fruit, ixnas, streams_xattr ) on my SMB shares, which does not appear to include zfsacl. I ran testparm to confirm and all of my SMB shares are showing this:

vfs objects = shadow_copy_zfs ixnas fruit streams_xattr

ixnas, fruit, and streams_xattr show up as selected in the Web UI for the shares, and I'm assuming that shadow_copy_zfs is included because I checked the Enable Shadow Copies box.

Any suggestions?

 

[anodos]

Thanks for the quick response, anodos. I'm afraid I'm not having the same luck as LarryG. I followed your instructions, but I'm still seeing the modified dates on copied files being set to the date/time that the copy occurred:

Code:

Cloned boot environment from 11.3-U1 then restarted FreeNAS:
root@nas01:/ # mount | grep boot
freenas-boot/ROOT/11.3-U1-ModifiedDateFix on / (zfs, local, noatime, nfsv4acls)

Copied replacement file into position:
root@nas01:/usr/local/lib/shared-modules/vfs # ll zfsacl*
-rwxr-xr-x  1 root  wheel  107149 Mar  1 20:02 zfsacl.so*

Restarted SMBD:
root@nas01:/usr/local/lib/shared-modules/vfs # service smbd onerestart
Stopping smbd.
Waiting for PIDS: 2198.
Starting smbd.

Created temporary directory on SMB share (O:\0)
Created directories on O:\0 for COPY, XCOPY, ROBOCOPY, and Windows Explorer
Used each method to copy a file from C: to O:\0\...

Source:
Directory of C:\Utility
02/25/2020  11:43 AM             2,236 MapDrives.cmd


Destinations:
Directory of O:\0\copy
03/01/2020  08:40 PM             2,236 MapDrives.cmd

Directory of O:\0\explorer
03/01/2020  08:41 PM             2,236 MapDrives.cmd

Directory of O:\0\robocopy
02/25/2020  11:43 AM             2,236 MapDrives.cmd

Directory of O:\0\xcopy
03/01/2020  08:40 PM             2,236 MapDrives.cmd

As you can see, ROBOCOPY is still the only method that is preserving the modified timestamp.

Out of curiousity, I also tried restarting FreeNAS after the test above, but the results were the same.

I noticed that the file that was modified was zfsacl.so, however I'm just using the default 11.3-RELEASE vfs objects plus fruit (i.e., fruit, ixnas, streams_xattr ) on my SMB shares, which does not appear to include zfsacl. I ran testparm to confirm and all of my SMB shares are showing this:

vfs objects = shadow_copy_zfs ixnas fruit streams_xattr

ixnas, fruit, and streams_xattr show up as selected in the Web UI for the shares, and I'm assuming that shadow_copy_zfs is included because I checked the Enable Shadow Copies box.

Any suggestions?

For now replace ixnas with zfsacl. Once again, there is an underlying FreeBSD kernel change that needs to happen. I can't fix that inside Samba's VFS or with a simple hotpatch.

 

[nharrington]

For now replace ixnas with zfsacl. Once again, there is an underlying FreeBSD kernel change that needs to happen. I can't fix that inside Samba's VFS or with a simple hotpatch.

I'm trying to understand how this reportedly works in 11.2 but doesn't in 11.3, and it now requires an underlying kernel change to fix it that can't happen until 12.0. Could you elaborate on this situation? What has changed and why can it be fixed via Samba for some but not others (i.e. can be patched to work if using zfsacl but not if using ixnas of 11.3)? Was it a kernel change that caused this issue?

 

[nharrington]

For now replace ixnas with zfsacl. Once again, there is an underlying FreeBSD kernel change that needs to happen. I can't fix that inside Samba's VFS or with a simple hotpatch.

Before I make the change from ixnas to zfsacl, are there any side-effects of making that change that I need to be aware of? What are the differences between the two options?

 

[amp88]

I'm having the exact same problem. The fact this wasn't mentioned anywhere in the release notes is really disappointing. It'd be great if there was an official procedure for restoring the "expected" behaviour (i.e. that file data metadata is preserved during file copies), because this is a real PITA.

 

[amp88]

Actually, saying that I was having the "exact same problem" isn't right. The last modified and creation dates for some (i.e. not all!) of my files are being overwritten with the copy time, but some have theirs preserved. The fact the behaviour isn't universal (i.e. applicable to all files) is really odd. Any comments? Attached an image where the last modified and created dates of the "1.MP4" and "3.CR2" files have been set to the copy time, but the "2.MP4" has its last modified and created dates preserved. In this example the files were copied from a Windows 10 machine to FreeNAS 11.3-U1 with the Directory Opus file explorer replacement.

 

[amp88]

@anodos Could you comment on the post above, please (i.e. this). If the problem with the last modified/creation dates, which wasn't present in FreeNAS 11.3-RELEASE and was introduced in FreeNAS 11.3-U1, is related to a FreeBSD kernel problem, why isn't it occurring universally (to all copied files)?

 

[anodos]

@anodos Could you comment on the post above, please (i.e. this). If the problem with the last modified/creation dates, which wasn't present in FreeNAS 11.3-RELEASE and was introduced in FreeNAS 11.3-U1, is related to a FreeBSD kernel problem, why isn't it occurring universally (to all copied files)?

Robocopy first sets a mtime of (01/01/1980) when /COPY:T is specified. FreeBSD's current behavior with timestamps is that if the mtime is older than the inode birth time (btime), it changes both the btime and mtime to the specified time. This has the knock-on effect that in FreeBSD it is impossible to set a btime that is newer than the mtime. This behavior was masked by Samba for some (but not all) users because Samba stores its own separate "create time" in the DOSATTRIB xattr when "store dos attributes = yes".
The temporary workaround was to refuse to set NT times that with a btime newer than the mtime (because it's impossible to do this on FreeBSD currently). As this thread has pointed out there are a significant amount of files with this sort of timestamp so the updated workaround will only ignore a very specific timestamp (the one sent by robocopy). This means that users with "store dos attributes = yes" and zfsacl can go back to business as usual, but the case of ixnas will be a little more nuanced. I will probably add a non-default auxiliary parameter to do the same (storing in an xattr) until the underlying issue is addressed. It will be non-default because the extra xattr reading has a negative performance impact.

 

[amp88]

OK, I appreciate your reply. If it makes any difference I'm using Directory Opus to copy files; not RoboCopy. Also, I would have appreciated some mention of this new behaviour (which clearly changes the function of a core feature of a NAS) in the release notes. I've wasted about a day trying to recover from this change, because it caused havoc with backup software (which detected ~50000 files as needing backed up), and now I'm going to have to go back to FreeNAS 11.3-RELEASE and restore from backup to avoid this bug.

 

[nharrington]

Robocopy first sets a mtime of (01/01/1980) when /COPY:T is specified. FreeBSD's current behavior with timestamps is that if the mtime is older than the inode birth time (btime), it changes both the btime and mtime to the specified time. This has the knock-on effect that in FreeBSD it is impossible to set a btime that is newer than the mtime. This behavior was masked by Samba for some (but not all) users because Samba stores its own separate "create time" in the DOSATTRIB xattr when "store dos attributes = yes".
The temporary workaround was to refuse to set NT times that with a btime newer than the mtime (because it's impossible to do this on FreeBSD currently). As this thread has pointed out there are a significant amount of files with this sort of timestamp so the updated workaround will only ignore a very specific timestamp (the one sent by robocopy). This means that users with "store dos attributes = yes" and zfsacl can go back to business as usual, but the case of ixnas will be a little more nuanced. I will probably add a non-default auxiliary parameter to do the same (storing in an xattr) until the underlying issue is addressed. It will be non-default because the extra xattr reading has a negative performance impact.

Thank you for that explanation, anodos. Much appreciated.

 

[nharrington]

One follow-up question...when did this issue arise...in the transition from 11.2 to 11.3, or 11.3 to 11.3-U1?

 

[amp88]

One follow-up question...when did this issue arise...in the transition from 11.2 to 11.3, or 11.3 to 11.3-U1?

I'd like to get an official reply, but I just nuked my 'broken' 11.3-U1 install (which was upgraded from an 11.3-RELEASE install) and made a fresh 11.3-RELEASE install. I didn't change any of the attributes for the shares (e.g. swapping ixnas for zfsacl); just created datasets with atime off, and Share Type SMB, and when I copy files to them the last modified and created dates are preserved, as they should be. So, at least in my experience: 11.3-RELEASE = working, 11.3-U1 = broken.

 

[LarryG]

According to documentation for smb.conf, store dos attributes=yes is the default for samba. So there is no need to specifically set it; I didn't in my config. Just replaced the default FreeNA zfsacl.so with the modified zfsacl.so provide by anodos. Replaced the reference to ixnas with zfsacl.

By the way, when I worked with the original 11.3-RELEASE, I found a major problem with sending emails from my FreeNAS server to google relay-mail accounts. The mail sent was corrupted. If you're using the email function to send server reports to external email accounts you might want to check if they still work properly in 11.3-RELEASE. I had to upgrade to 11.3-U1 where I found the email problem was corrected.

 

[amp88]

According to documentation for smb.conf, store dos attributes=yes is the default for samba. So there is no need to specifically set it; I didn't in my config. Just replaced the default FreeNA zfsacl.so with the modified zfsacl.so provide by anodos. Replaced the reference to ixnas with zfsacl.

By the way, when I worked with the original 11.3-RELEASE, I found a major problem with sending emails from my FreeNAS server to google relay-mail accounts. The mail sent was corrupted. If you're using the email function to send server reports to external email accounts you might want to check if they still work properly in 11.3-RELEASE. I had to upgrade to 11.3-U1 where I found the email problem was corrected.

Thanks for the heads up. I haven't tested that yet, but will have a look. I've been testing various versions of FreeNAS for a while now (from 11.2-U7 through to 11.3-U1), and I've found various bugs or problems in each one, unfortunately. Luckily I haven't actually fully migrated to using it day to day though, so it's just causing me frustration and lost time; nothing valuable! ;)

 

[rolandinoo]

Having same issue, which is indeed annoying. It happened with the update from 11.3-RELEASE to U1.
The zfsacl.so workaround is working for now, thank you for that.

This really needs to be fixed in next update.

 

[TimoJ]

Replacing the zfsacl.so didn't fix the problem for me, unless I did something wrong... Downgraded to 11.3.release and the problem is solved. I'm using Total Commander for copying, Win10 Pro system.

 

[msim888]

Hi there!

 

[msim888]

I've experienced the same timestamp issue after U1 update (11.3-U1). 11.3-RELEASE worked well for me.
I've experienced the same thing with Windows File Explorer copy and move as well as Powershell Copy-Item and Move-Item commandlets.
Even if I set the correct timestamp manually after the file copying or moving FreeNAS changes it in a few seconds again.

 

[msim888]

anodods workaround patch works for me.
Thanks!

 

[TimoJ]

anodods workaround patch works for me.
Thanks!

So how did you install it?