Folder dates are not kept original on replicas

[Morganlej]

Steps to reproduce

1. Share a folder with subfolders and files from a computer to another user.
2. Watch the folder tree as recieved on that users computer

Expected behaviour

Files and folders should have original timestamps
(like it usually works with cloning/backup utilities)

Actual behaviour

Folders are timestamped with the time they were downloaded!
This mess up history for both users and some programs.
(Files are OK get correct original time.)

This seem to be a long standing problem reported on forum and several issues here, examples: #7009, #2076, #1897, #1566. Anyway I was asked to make yet a new issue so here it goes.

I see the same still today windows & linux clients 1.7.1 server 7.0.4
* IMO this really need to get straight as it disturbs many users.*

Why it is a problem: Wrong times can fool both people and programs.

Basically it seem to operate by design as it seem not to be logging any problem, and bug reports get closed. But we are many that think that the design goal should be to replicate the original folder creation time.

Real world example: I make many small repair projects which i document in an tree and just make a new folder and put in a couple photos and text file. There are many such folders in a customers folder. When i sort it by time i can easily se when repairs were made, and easily find the one i look for. But when ownCloud resets the folder creation time i need to open each folder to see the time of the files instead!

Server configuration

I wrote this while setting it up: https://wiki.mageia.org/en/OwnCloud

Operating system: Mageia 5 beta 2+ , 64 bit, kernel-desktop-3.18.3-2.mga5

Web server: Apache 2.4.10-11.mga5

Database: MariaDB 10.0.15-2.mga5

PHP version: php 5.6.5-1.mga5

ownCloud version: ownCloud 7.0.4-1.mga5

Updated from an older ownCloud or fresh install: Fresh (i believe i cleared all old away after first test setup)

List of activated apps: I only use (in-house) file sharing...

The content of config/config.php:

Insert your config.php content here
(Without the database password, passwordsalt and secret)

Are you using external storage, if yes which one: ext4 on separately mounted partition, SATA mechanical platter

Are you using encryption: No

Client configuration

Browser: Firefox for web UI, Dolphin and Konqueror for files, Webmin... Er... Do you mean what you other places call the Client? version 1.7.1 on both Linux and Windows

Operating system: Mageia5 KDE, and Windows7 : identical behaviour

Logs

Web server error log

It is long for other reasons, see nothing suspicious, what should i search for?

ownCloud log (data/owncloud.log)

I see nothing suspicious, what should i search for?

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log 
c) ...

I dont think you need them...

[PVince81]

CC @dragotin

[Morganlej]

Still valid client 1.8.0, server 8.0.3 in Apache with MariaDB, php 5.6.8, no php caches.

[enoch85]

@Morganlej Any difference with 1.8.1 client?

[Morganlej]

1.8.1 build 5050 git ee7102 Qt5.4.0, running on W7pro 64bit swedish, operating on SSD drive D:, NTFS whatever version set to not store 8dot3 names.: still valid.
(I wait to test on Linux until my distro release that package)

[Morganlej]

I simply moved an old folder into a folder i already shared on one computer as one user (client 1.8.0, linux), sharing to another user on same owncloud server, and on that users laptop (clinet 1.8.1, W7) the folder showed up with current datetime.
How does it work for you?

[PVince81]

The current behavior is by design, folder mtimes are not synced.

Switching labels to "enhancement"

[Morganlej]

This enhancement would be nice.
Until we have it: is current behaviour explained in manual or FAQ?

[ktuulos]

It is weird, that this is classified as "enhancement" instead of "bug", as for end user point of view, owncloud should behave transparently i.e. it should not mess with file timestamps. At least for me (and most likely for majority of Windows and Mac users), file timestamps are very important information to quickly detect, which documents have been last edited. Also operating systems offer tools to search based on file and folder timestamps.

I realize, that in Git ideology, timestamps don't matter, but owncloud is not git - it is more like open source replacement for DropBox. So I sincerely request that this would be classified again as a "bug".

[ogoffart]

The problem is that the timestamp of the folder changes each time we do changes to that folder.
So each time the client download a file, because we have the create a temporary file, it changes the mtime of the folder.
For this reason there is no point in trying to keep the mtime of folder in sync.

The mtime of the files on the other hand, are kept in sync.

[ktuulos]

I'm sorry, but the explanation "because we have the create a temporary file, it changes the mtime of the folder" is not valid, at least not in Unix world.

It is trivial to set the timestamp of directory back to what it was before creating the temporary file, just one touch command. Is there something more complicated behind this?

[PVince81]

Could the temporary file get stored elsewhere, for example in a hidden folder under the root ? This would prevent touching the folder mtime.

[rekster]

Any updates on this? I'm having the same issue. Modification dates of folders are being set to the date they are synced, not the date of the folder on the source. This is creating major nightmares keeping track of things. This is not an ENHANCEMENT, this is a BUG!!

[stale]

This issue has been automatically closed.