OES11 SP1 Migration - File sync phase copies all files instead of syncing only modified data.

  • 7014343
  • 20-Dec-2013
  • 17-Jan-2014

Environment

Novell Open Enterprise Server 2 (OES 2)
Novell Open Enterprise Server 11 (OES 11) Linux Support Pack 1

Situation

The environment is as follows :
  • OES2 SP3 server running NSS volumes (Source server)
  • OES11 SP1 server running NCP exported volumes over POSIX (Destination server)
  • OES11 SP1 Migration tools
  • September 2013 OES Scheduled Maintenance patch
Once the initial data migration has been performed, a final sync for any modified data since the data migration is performed. It was observed that not just the modified data was synchronized between source and destination again, but the complete data set was migrated from source to destination again.

Options selected for the data sync are: "copy If Newer" and "Delete Files Not on Source".

Resolution

In the case the destination server is OES11, and running (NCP exported over) POSIX volumes, the process now avoids comparing  'createDateAndTime' metadata where this is not set and since POSIX does not store the creation time.

Cause

As POSIX does not store creation time (note: only stores access, modification and change) for file(s)/folder(s) we were not receiving the 'createDateAndTime' metadata for POSIX volumes.

As NSS volumes store file creation time where POSIX volumes do not, there is no point of checking and comparing the createDateAndTime metadata on both the Source and Destination server, in the scenario where the destination server runs (NCP exported) POSIX volumes and not NSS.

Additional Information

Note 1:
Please note that due to an oversight, the solution to this problem is unfortunately two-folded :

- the first part of the solution is when using the cli (only).
  This will be resolved with the January 2014 Scheduled Maintenance patch for OES 11.

- the second part of the solution when using the Miggui.
  This will be planned for the next Scheduled Maintenance patch for OES 11 following January 2014.


Note 2:
This fix would also apply in the case where the source server would be NetWare.
In the scenario where the NetWare source server is :

NetWare 5.1 SP8 :
- Please make sure the server is at least installed with the minimum support DS.NLM from patch edir8737.exe
- Latest tsa500 has been installed from nw51sp8tsa500.zip

NetWare 6.0 SP5 :
- Please make sure you extract both the tsafs.nlm and smsut.nlm from the latest available tsa5up24.exe patch that was released for NetWare 6.5, and apply these to he NetWare 6.0 SP5 server.