I'd like to migrate an NTFS data partition, so that it becomes available either as an own virtual drive or inside a folder of my home directory to all operating systems I am running under Parallels 13.2.0. In doing so I would like to keep all attributes, especially the modification date, the creation date AND the last access date unchanged. I have installed and tried about a dozend synchronizing and specialized copying programs - the last access date is never kept. Copying or synchronizing the data into a folder doesn't seem to be the way to go about it. Can anyone give me any hint what other approach might work? - Thanks a lot in advance.
How to migrate a NTFS data partition while keeping all attributes unchanged?
- Thread starter MarcelM4
- Start date
Not really. Zip archives don't record the last access date. The only thing I know so far are programs which mirror and restore a whole partition like Paragon's drive copy. Can Parallels simply mount drive copies?
I have found a software (ViceVersa) which can mirror the last access date - and it does so correctly on a dedicated Windows 7 PC. However, if I try to do so in Windows 7 under Parallels, it doesn't work at all. I have been using the same settings in ViceVersa, and tried both,
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]"NtfsDisableLastAccessUpdate" set to dword:00000001 or to dword:00000000.
I tried to mirror to a shared folder and I tried to mirror to an NTSF-formatted USB disk - no difference, the last access time and date are always the time and date of copying. Does Parallels somehow interfere with the copying process and if yes, can that be avoided?
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]"NtfsDisableLastAccessUpdate" set to dword:00000001 or to dword:00000000.
I tried to mirror to a shared folder and I tried to mirror to an NTSF-formatted USB disk - no difference, the last access time and date are always the time and date of copying. Does Parallels somehow interfere with the copying process and if yes, can that be avoided?
Let me see whether I understood this right: You are saying
1) no matter how a Windows program might approach the copying/mirroring of a file there is no way to write files into a shared folder without the last access date becoming changed in the process, because Parallels somehow gets involved - and there are no settings which can tell Parallels not to get involved?
2) Parallels does not interfere with an USB-disk/stick if the USB-disk is not shared between OSX and Windows but exclusively connected to Windows?
Did I understand you correctly?
1) no matter how a Windows program might approach the copying/mirroring of a file there is no way to write files into a shared folder without the last access date becoming changed in the process, because Parallels somehow gets involved - and there are no settings which can tell Parallels not to get involved?
2) Parallels does not interfere with an USB-disk/stick if the USB-disk is not shared between OSX and Windows but exclusively connected to Windows?
Did I understand you correctly?
Do you have any idea how long that would take? If we are talking about 1-2 month I'd postpone my project.
vasilyz
Parallels Developers
We've thoroughly retested Parallels Shared Folders behavior in relation to setting access times and found out that PSF correctly set access times. But there are two problems that affect access times after that.
1) Viewing a non-empty file's properties in Windows makes a read from the file (tested on Windows 10) and that read immediately updates access time. The problem isn't reproduced for local files because of "NtfsDisableLastAccessUpdate" option in the system registry (that option makes the NTFS driver to stop accounting accesses to files when they are read). If you turn that option off you would reproduce the problem for local files too.
2) There is mdworker utility that is a part of OSX mechanism that is responsible for indexing and watching filesystem changes. And when a change to a file or its attributes is detected it makes a read from that file. And that updates access time again. Unfortunately we couldn't find a way to prevent that.
That said you may close all Finder and Explorer windows to make sure that filesystem watching isn't active and then mirror you files to a shared folder with correct access times, but once you open a Finder window the access times would get updated.
1) Viewing a non-empty file's properties in Windows makes a read from the file (tested on Windows 10) and that read immediately updates access time. The problem isn't reproduced for local files because of "NtfsDisableLastAccessUpdate" option in the system registry (that option makes the NTFS driver to stop accounting accesses to files when they are read). If you turn that option off you would reproduce the problem for local files too.
2) There is mdworker utility that is a part of OSX mechanism that is responsible for indexing and watching filesystem changes. And when a change to a file or its attributes is detected it makes a read from that file. And that updates access time again. Unfortunately we couldn't find a way to prevent that.
That said you may close all Finder and Explorer windows to make sure that filesystem watching isn't active and then mirror you files to a shared folder with correct access times, but once you open a Finder window the access times would get updated.
Thank you VERY much for your thorough investigation and exhaustive answer. I understand from your explanation, that it would be useless to keep date-critical files on sa drive shared between OSX and Windows. I have tried to circumnavigate the problem by keeping the date-critical files in an NTSF-partition on a micro-SD card in the Apple card reader and assign the card reader exclusively to Windows. This, however is not a satisfying solution, because the card-reader tends to disconnect from Windows when the laptop goes into sleep mode (after shutting the lid). I have raised this issue in another thread.