Maintaining modify timestamps on directory tree

[guy-rouillier]

I'll try to be brief on my initial post, and fill in any additional requested details as they come up. I'm using rsync to back up computers on my home network onto a QNAP NAS, also on the network. I mount the NAS locally so I don't need to supply credentials for every sync. My basic challenge is that rsync will not maintain the modify timestamp on all directories when syncing absolute directory paths. I'm testing from an msys2 environment on Windows 7 64-bit using a Samba mount, and from an Ubuntu MATE 22.10 64-bit virtual machine using and NFS mount.

With absolute paths: (Windows example, rsync  version 3.2.7  protocol version 31)
rsync -rltD --mkpath --delete /d/Projects-Linux/gcvs /n/Projects-Linux-2/gcvs/

With this, the modify timestamps on the top-level contains the current timestamp instead of the source timestamp. The timestamps on lower-level directories and individual files are all correctly maintained. I get the same results running from Ubuntu.

Following some suggestions I found via Google, I switched to relative directories:

With relative paths: (Linux example, rsync  version 3.2.5  protocol version 31)
rsync -rltD --mkpath --delete --relative /mnt/win/./Projects-Linux-2/gcvs/ ~/mnt/fastnas/

This works perfectly. All directory timestamps are the same as on the source drive.

Should this work using absolute paths? Thanks.

[EDIT] I found a simpler way to demonstrate. NAS isn't required at all, I get the same results syncing between two local directories. Under Windows:
rsync -rltD --mkpath --delete /d/Projects-Linux/gcvs/ /d/test/Projects-Linux/gcvs/

Both the test and Projects-Linux directories end up with current timestamps. The gcvs directory and files within it maintain the source timestamps.

[WayneD]

Those are still absolute paths, since ~ translates into a top-level directory. So, yes it works fine with absolute paths. Remember that if you want a directory's attributes preserved, it must be a part of the transfer. Using --mkpath specifies directories that are outside the transfer.

[guy-rouillier]

Thank you for the reply. ~ simply represents my home directory. What makes the rsync relative is the inclusion of the --relative parameter.

I tried some more using just local directories, since that is easier. I'm running msys64 under Windows 7 Pro. Here is my (partial) source directory:

 Directory of D:\Projects-Linux

05/29/2010  11:47 PM    <DIR>          gcvs
05/24/2010  05:27 PM    <DIR>          gcvs2
05/29/2010  11:47 PM    <DIR>          gtkwindow
05/29/2010  11:47 PM    <DIR>          mono
05/29/2010  11:47 PM    <DIR>          settings
05/29/2010  11:47 PM    <DIR>          zed-1.0.5

 Directory of D:\Projects-Linux\gcvs

05/24/2010  05:27 PM               221 gcvs2-autogen.changes

If I execute
rsync -rltD /d/Projects-Linux/ /d/util/rsync/test/Projects-Linux/
then the results are as expected; the directory structure and timestamps are all properly maintained.

However, if I try to sync a single lower directory by itself, with no target directory already in place, it fails with this:

D:\util\rsync>rsync -rltD  /d/Projects-Linux/gcvs/ /d/util/rsync/test/Projects-Linux/gcvs/
rsync: [Receiver] mkdir "/d/util/rsync/test/Projects-Linux/gcvs" failed: No such file or directory (2)
rsync error: error in file IO (code 11) at main.c(789) [Receiver=3.2.7]

If I switch to
rsync --mkpath -rltD /d/Projects-Linux/gcvs/ /d/util/rsync/test/Projects-Linux/gcvs/
the command completes successfully, but the timestamp on the top level directory Projects-Linux has the current timestamp, rather than the source timestamp.

Finally, if I use relative, the command completes successfully and the directory structure and timestamps are all properly maintained.
rsync --mkpath -rltD --relative /d/./Projects-Linux/gcvs/ /d/util/rsync/test/

Thanks. In reality, this will not be a limitation for me. I use rsync to create backups, and I only ever backup top-level directories.

[Semnodime]

To preserve a directory's attributes, it must be a part of the transfer.
To copy foo/bar's content (but not foo/secret) from /source/foo/bar/ to /target/foo/bar/ while preserving the attributes of both foo/bar and foo, you can use rsync -a --relative /source/./foo/bar/ /target/.

[Semnodime]

The fact that this discussion is marked as unanswered tempted me to summarize the discussion's apparent solution. Please mark it answered.