Opgelost Synchronisatie software met behoud van datum en tijd

Dit topic is als opgelost gemarkeerd
Heb ook nog een directory met subdirs via winrar ingepakt bij de bron en uitgepakt bij de doel (Sharepoint) en dan zijn de datum/tijd van ook de bestanden goed. Dus het kan wel maar dat is heel anders dan synchronisatie software.
 
En terug naar de bron van het probleem. Waarom zijn datum/tijd zo belangrijk? Als dit soort zaken bedrijfskritisch zijn geworden dan is het hoog tijd voor een documentmanagement systeem.

Want heel eerlijk, die kunnen op elk willekeurig moment gewijzigd worden. Oftewel die dingen zijn een verre van betrouwbare bron van informatie. Zeker in je online omgeving.
 
Er is een code ontwikkeld die een foute datum/tijd kan negeren en dus de originele kan nemen.
Heb er op gezocht en vond dit web artikel:
WebDAV

WebDAV protocol does not have any command that would allow a DAV client to set a files modified time or creation time; however WebDrive has a method of pseudo support for setting a files modified time on the server. WebDrive accomplishes this with custom DAV properties. When a file system request comes into WebDrive to set a files modified time, it will set the following custom DAV properties on the server for the file in question.

Custom DAV Properties used by WebDrive:

  • "srt_modifiedtime" - set to the modified time requested by the file system
  • "srt_creationtime" - set to the creation time requested by the file system
  • "srt_proptimestamp" - this value is set to whatever value the server returns for the "getlastmodified" property for this file
Note: Not all WebDAV servers allow clients to set custom properties. Please check your server to see if it's enabled. For Apache, these custom properties when enabled are stored in a .DAV folder under the folder in which the files are uploaded to.

So when WebDrive uploads a local file called John.txt with a local date/time of "Dec 1, 1998 4:00PM" to the WebDAV server, it will set a property called "srt_modifiedtime" to "Dec 1, 1998 4:00 PM". When WebDrive requests the directory listing the server will respond with something that looks like this:

PROPFIND /mydir
<filename> John.txt
<getlastmodifiedtime> March 22, 1:37 PM - controlled by server, not WebDrive
<srt_modifiedtime> Dec 1, 1998 4:00 PM
<srt_proptimestamp> March 22, 1:37 PM


The server assigns "getlastmodifiedtime" to the current date/time, in this example March 22, 1:37PM. When WebDrive parses this listing it sees the getlastmodifiedtime from the server, which is totally controlled by the server and can't be set by WebDrive. WebDrive also sees the "srt_modifiedtime" property and will use that time when displaying file times in explorer in the windows file system. So the user will see "Dec 1, 1998 4:00 PM" as the files modified time even though it's not the file's actual time on the server. This is useful because backup software will not see the intended time of the file.
It would be very useful if this supported by TC WebDav pluging.
Of het TC webdav plugin Team heeft hier op geanticipeerd heeft?

Workaround:
Many dav servers like "Yandex" and "pCloud" allow clients to set custom DAV properties, some like "Koofr", "PowerFolder" not, and Apache servers store custom properties (when enabled) in a .DAV folder under the folder in which the files are uploaded to.
So a dav client (like TC WebDav pluging) can set the following custom DAV properties on the server for the file in question:


Code:
"srt_modifiedtime" - set to the modified time requested by the file system
"srt_creationtime" - set to the creation time requested by the file system
"srt_proptimestamp" - this value is set to whatever value the server returns for the "getlastmodified" property for this file
So when client uploads a local file called John.txt with a local date/time of "Dec 1, 1998 4:00PM" to the WebDAV server, it can set a property called "srt_modifiedtime" to "Dec 1, 1998 4:00 PM". When dav client requests the directory listing the server will respond with something that looks like this:
Code:
PROPFIND /mydir
<filename> John.txt
<getlastmodifiedtime> March 22, 1:37 PM     - controlled by server, not dav client
<srt_modifiedtime> Dec 1, 1998 4:00 PM
<srt_proptimestamp> March 22, 1:37 PM
The server assigns "getlastmodifiedtime" to the current date/time, in this example March 22, 1:37PM.
When dav client parses this listing it sees the getlastmodifiedtime from the server, which is totally controlled by the server and can't be set by dav client.

De laatste zin: When dav client parses this listing it sees the getlastmodifiedtime from the server, which is totally controlled by the server and can't be set by dav client.
geeft aan dat als je het zo regelt, de server in de lead is en de webdav client kan niet ingrijpen, simpel omdat door de ingreep de reeds voorgebakken datum/tijd alleen maar kan overnemen.
Ik heb helaas nog geen 100% zekerheid of die code er nu bij de TC webdav plugin inzit.

Het is dan nog steeds mogelijk dat het iets uit die tabel van mijn vorige reactie zou zijn, maar das een aanname.
 
Laatst bewerkt:
Eindelijk een follow up van mij. Uitendelijk lag het probleem én aan de software die verbinding maakt met Sharepoint én aan de diverse migratiesoftware die ik testte. De software RaiDrive, die de verbinding maakte met Sharepoint, daar moest ik een (verborgen) vinkje plaatsen bij "probeer wijzigingsdatum te handhaven bij kopieren". Daarmee was ik er nog niet, want bijvoorbeeld FreeFileSync trekt zich daar niets van aan. Maar met het volgende Robocopy commando werkt het prima:
Code:
ROBOCOPY "S:\bronmap" "Z:\doelmap" /MIR /COPY:DT /DCOPY:T

Voor mij is de vraag opgelost, dank jullie allen voor alle tips en meedenken!
 
Terug
Bovenaan Onderaan