[gpfsug-discuss] Creation time

Jonathan Buzzard jonathan.buzzard at strath.ac.uk
Thu Oct 1 14:24:00 BST 2026


On 01/10/2026 14:18, Michael Neumayer wrote:

> 
> If you can use rsync (Linux) or robocopy (Windows) for the sync,
> preserving dates can be configured via the available options of
> these and similar tools. You may as well have a look at rclone
> (https://eur02.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Frclone.org%2F&data=05%7C02%7Cjonathan.buzzard%40strath.ac.uk%7Cbb8b6aa3d2c645bf361d08df1fbe756c%7C631e0763153347eba5cd0457bee5944e%7C0%7C0%7C639264575017981990%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Q2HB649QLcXoqVnqSy8v1Qv76sYR7st8rtAZhKveK4k%3D&reserved=0).
> I haven't used it a lot so far, but a colleague of mine did some
> large migrations with it, and was quite happy about it.
> 
> I've never tried, but if you still have the external file system
> available, you could probably use the mentioned tools just to update
> dates to their value on the source file system without transferring
> them again, in case you've already finished the sync.
> 

rsync notably does *not* preserve creation/birth time. Notably because 
there is no consistent API for doing so. Some file systems (aka XFS at a 
minimum) won't let you change the creation time for "forensic" reasons. 
Though one presumes you could start messing with the system clock a lot 
to fudge the issue :-)

The standard atime,mtime,ctime is not an issue, though doing any sort of 
sync jiggers your atimes if you take multiple passes. Note ctime is 
*not* creation/birth time but last time you changed permissions.


JAB.

-- 
Jonathan A. Buzzard                         Tel: +44141-5483420
HPC System Administrator, ARCHIE-WeSt.
University of Strathclyde, John Anderson Building, Glasgow. G4 0NG


More information about the gpfsug-discuss mailing list