Robocopy to an FLR enabled file system changes the LastTimeWrite-Date to 02.01.1980
Summary: Migrating data to a Unity FLR enabled file system results in the lastTimeWrite-Date being changed for some files to a time in 1980.
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Symptoms
- The command that is used for the copy is similar to:
robocopy \\x.x.x.x\copyfrom\ \\y.y.y.y\copyTo\sample /COPY:DATSO /W:1 /R:1
Here is an example of the files after being copied:
- The customer tried copying from multiple different source devices, but the result is always the same.
- During troubleshooting, the following changes were made but the issue was not resolved:
- Set the param windowsTimeUpdate to 1.
- Turn on SMB1.0/CIFS File Sharing Support feature on the robocopy host, and reboot the PC:
- Program and features > Turn Windows features On or off > SMB1.0/CIFS File Sharing Support
- Usually, in Windows the check box is disabled, Please check and reboot the PC.
- Network Traces show a lot of "access denied" responses to SMB SETINFO requests.
Cause
Robocopy is working as designed.
During normal operation, it modifies the mtime twice. First time, it resets the year to 1980. Once the write of the data succeeds, Robocopy then changes the mtime to reflect the correct last modified time.
However, if autolock is enabled when creating the FLR file system, when Robocopy resets the mtime to 1980, it immediately triggers a protected state as WORM_OK, so the file becomes read-only. This makes it impossible for the mtime to be modified the second time around, to reflect the correct last modified time, and "access denied" is logged in the Robocopy report.
Empty files with 0 bytes are put in an append-only state since FLR thinks there is no data that needs protection. The state is set to WORM_CLEAN, which means the autolock feature does NOT take effect on an empty file by design, so the empty files mtime is as expected.
During normal operation, it modifies the mtime twice. First time, it resets the year to 1980. Once the write of the data succeeds, Robocopy then changes the mtime to reflect the correct last modified time.
However, if autolock is enabled when creating the FLR file system, when Robocopy resets the mtime to 1980, it immediately triggers a protected state as WORM_OK, so the file becomes read-only. This makes it impossible for the mtime to be modified the second time around, to reflect the correct last modified time, and "access denied" is logged in the Robocopy report.
Empty files with 0 bytes are put in an append-only state since FLR thinks there is no data that needs protection. The state is set to WORM_CLEAN, which means the autolock feature does NOT take effect on an empty file by design, so the empty files mtime is as expected.
Resolution
The following workaround allows the mtime to be updated correctly.
- Create an FLR file system on the destination array.
- Disable Autolock on this file system (option under file system properties).
- Robocopy all those files that need FLR protection to the destination array.
- Enable Autolock on the destination file system (click the check box).
- If new files must be copied to the destination FLR file system, disable Auto-Lock first.
- Then Robocopy those files to the destination FLR file system.
- Enable Autolock again.
Affected Products
PowerStore, Dell EMC Unity, VNX/VNXeArticle Properties
Article Number: 000187051
Article Type: Solution
Last Modified: 29 Aug 2022
Version: 6
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.