and rclone sets all created times to now() instead of keeping the original value.
Windows (didn't try linux) shell copy will preserve these times when copying files from one drive to another so this should be possible for rclone as well. If not desired it hasn't to be the default but at least an option via a --keep-created switch would be nice...
Rclone preserves the modified date. Rclone was born on unix platforms which don't support created date so rclone doesn't currently have a concept of created date.
Would setting the created date to the modified date be acceptable? That would be easy and might be a better thing to do for remote -> local copies.
When doing a local -> local copy it might be possible to read the created date.
hi ncw,
for me, rclone cannot become a viable solution for local copying on windows.
too many features to add and too many years of testing before i could be trust it.
and that is a good thing as all i want from rclone is to sync files to cloud with check-summing.
but since you asked, all the features listed here. https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy
most important is that rclone must not change the files being copied, such as creation date.
/efsraw Copies all encrypted files in EFS RAW mode. /sec Copies files with security /copy:<CopyFlags> Specifies the file properties to be copied.
Thanks for the offer, ncw, but I'm afraid this wouldn't help much. Getting the creating date/time (sometimes it's called birth time on windows) is possible. E.g. take a look at this library here:
Robocopy doesn't have versioning inbuilt and I simply love rclone for its speed...
i agree that robocopy does not have versioning and that is a critical feature.
i never use robocopy for backups. i use robocopy for moving\copying around files on an adhoc, as needed basis. robocopy can do something few tools can do, copy EFS files in RAW mode from server to server and NOT have to decrypt the files during the copy/move, which is critical if you have to deal with HIPAA regulations and audits.
also, robocopy will not use checksums at all. neither to determine what needs to be copied or to verify what has been copied has been copied without error so it cannot be trusted for backups.
and for speed, you cannot beat fastcopy which can use checksums
for versioning, i have a couple of solutions.
for backup of critical infrastructure such as servers, i use veeam backup and replication, which has versioning and a whole lot more and use rclone to copy that to the cloud.
for certain data folders, i have a script that will compress a folder into a .7z with the date and time embedded in the filename and use rclone to copy that to cloud.
i never use windows explorer for anything, i use double commander
for huge copy,
my first choice is fastcopy, as it can checksum files. i have integrated fastcopy to work from inside double commander.
if i need special functionality, i use robocopy.
