Modification date of an initially synchronized directory on client is not set to the modification date of the corresponding directory on the server

[herrep]

Actual behaviour:
The modification date of a directory easily changes, e.g. when creating a temporary file inside the directory or when adding or deleting files. Therefore, the modification date of directories is not synchronized between client and server.

Drawback of the actual behavior:
In many environments, there are a lot of directories which are not touched at all; i.e. the modification date of such directories do not change at all. The users can notice this by checking that the modification date indeed does not change and remains old. But this concept of monitoring directories that are not touched for a long time do not work when working on a "fresh client" that needs to be synchronized first: Upon the initial sync of a directory, the directory at the client has the current date as creation and modification date. Therefore, when watching all the directories at the client, it appears that even directories which have not be touched for ages appear to be regularly used, as they all have the same modification date when creating the directories for the initial sync.

Desired behavior:
It is suggested that, only upon an INITIAL sync of a directory on the client, when the directory needs to be created first, the creation and modification date of this directory at the client is set to the creation and modification date of the corresponding directory on the server.
Obviously, later changes of the modification date of directories do not need to be synchronized in order to save resources.

[herrep]

Thank you for considering the reported issue. Much appreciated.

[herrep]

Would you also mind to set the creation date (ctime) of the local directories to the creation time of the corresponding directories on the server? Only upon creation if the local directory, as set out above with respect to mtime?

[ckamm]

About ctime: I don't think anything else in the client adjusts ctime and it's not stored on the server. I agree ctime > mtime is odd and setting it to mtime on creation would probably be nicer. That's a larger and different change though (feel free to make a new ticket).

[guruz]

ctime is inode change time, not creation time
https://en.wikipedia.org/wiki/Stat_(system_call)#ctime
The ownCloud WebDAV protocol does not have support for that, we use the ETag of the parent directory instead to notice that the file metadata changed (and file ETag to notice that contents changed)

[ckamm]

Thanks, yes, I didn't mean ctime. I meant the Windows creation time that @herrep was asking about.

[HanaGemela]

2.6.0alpha2 (build 12097), Windows 10
2.6.0alpha2 (build 12128), macOS 10.14.5

@ckamm @guruz Have you done anything with the creation date?

Currently the modification time is the same as on the server for both files and folders, Windows and macOS.

The creation date on macOS is the same as modification date, on Windows creation time is the time at the point of downloading. This is inconsistent.

[ckamm]

@HanaGemela No, the client doesn't manually adjust change time or creation time. Creation time isn't stored on the server, so at best we could set it to mtime initially. That'd be a different issue though.