-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need ctime of files after uploads #3572
Comments
Wow, huge problem. |
Maybe |
Unfortunately, no. The column storage_mtime contains the same value as mtime. After an upload over the web gui the original (old) mtime is set too. OS: Windows 10 |
The client does this by design. Because if you edit something while you have no connection you don't want to see a changed time on the web wich differes (also you will most likely redownload the file then). From my POV keeping the time of the file is correct. We should just also keep track of the uploaded time. |
#3822 mostly fixes this imo |
Well it doesn't really help with the retention app, the behaviour is still "undesired/unintentional". |
I would argue that with retention you do want the original mtime from the sync client. If retention is set to 14 days, I expect it to trigger 14 days after I create the file, regardless of the fact that the client was offline for a week. |
Well but when you created the file four weeks ago and just put it into the sync folder just now. You don't want it to be deleted in the night when retention triggers, but 2 weeks after upload? |
Hi, we facing the same issue. The uploads should get automatically deleted after 14 days after upload. Hopefully it will be fixed soon because this is a showstopper for our planned rollout. |
We really need to look into this. |
I´ve seen that the milestone was modified from 12 to 13 a month ago. Is there already a commit which changes the behavior with ctime? |
Damn really bad news for us! |
Any progress on that one? |
Any progress on that one? |
@rapITler and others: if this is a issue for an enterprise PoC/deployment, contact our sales team, we can help either find an alternative solution or speed up fixing this. |
@icewind1991 Mind to have a look into collecting the cdate as well? |
I'd like to reference #15192 here, "Consistent handling of last modified dates when copying/moving files" ... it seems like different nextcloud components have different ideas about what to do with the dates. |
Hi @nickvergessen @rullzer, for the moment, as a "workaround" what I'm doing is creating a 1day file-retention, manually executing cron.php and deleting the previously created 1day file-retention. Of course, it's not a good solution because not all files will be deleted (but almost all of them) and also because you need to do this manually. Until a solution is found, that could nearly solve my problem. Regarding that, is it possible to execute a script to create a 1day file-retention, executing cron.php and deleting 1day file-retention? I could'nt find a working way to create or delete file-retentions. That would be great. |
Possible that this is open from Feb. 2017 without a serious milestone ? |
Could someone please explain why the behaviour differs depending on file size? It seems that files which are 10 MiB and less get their timestamp rewritten to upload time, while bigger files keep the original modify date. I created 3 files with dd locally:
and uploaded separately to my home folder with "+" > "Upload file".
PS. As a workaround to have retention working as expected I added flowupload app and asked users to use that instead, since this always seem to update the modify time to upload time. Do you expect to fix this before the end of this year with 17.0.2 release? |
@juliushaertl I think you mentioned a fix for this? |
Yes, for the file upload of smaller 10MB files: #17847 |
Thank you for quick feedback! This makes it more clear why this happens. |
I guess that can be addressed once we have a dedicated column to store the upload time #17765 |
While waiting for a fix (NC18?) I found the cleanest workaround to have retention working properly for all files would be to remove X-OC-Mtime header via haproxy/nginx at the backend. Thank you! |
#17765 was merged. |
@jakubeliasz Did you have an example nginx config to do that? |
remove X-OC-Mtime header worded for me .
|
Ref nextcloud/files_retention#23
Steps
Expected
The file remains on the instance for 14 days
Actually
The file is immediately deleted, because the mtime of the file is 2016.
Problem
The problem is that since some time we use the original mtime of the file when writing the entry into the database instead of "current time". I don't know when that changed, but it's a bit annoying. Same happens with the "recent files" filter. It will not list such files, although you just uploaded them.
So we need some kind of timestamp when the file was first seen/discovered by nextcloud.
@icewind1991 you have any idea why and when this was changed?
Also cc @rullzer for the client, @MorrisJobke for the customer related issue and @schiessle as per yesterday.
The text was updated successfully, but these errors were encountered: