I use services in conjunction with deploy module to deploy content between environments. Just had a nasty thing happen in a production environment as a result of the following set of circumstances:
1. Files got deployed as dependencies of nodes and were saved on remote with status 0 and the timestamp from when they were originally created in a previous environment
2. Cron ran before the nodes got pushed so all the files got deleted because they were older than 6 hours (based on their timestamps) and had status 0
3. Nodes got pushed, but their files were already gone.

The attached patch ensures that the file is saved with the current time (i.e. on the remote, at the time of saving) instead of the original time that the node was created in a different environment.

I've set the priority of this as major because its consequences were disastrous in this particular instance. I don't know of any use case where hanging on to an old date that is relevant to a different environment is desirable.

CommentFileSizeAuthor
file_save_timestamp.patch905 byteskatbailey

Comments

katbailey’s picture

Follow-up: so, I got the feeling after a brief chat with heyrocker that it would be preferable if this could be dealt with on the deploy side. So I've written a patch to filefield_deploy that would do the same thing - #1038500: Reset the file's timestamp to the current time when deploying.
It still seems to me that the the timestamp reset should be happening when the file is actually being saved, i.e. here in file_service module. But I'm not familiar wiht enough different use cases so maybe I'm wrong.

kylebrowning’s picture

Its certainly preferable, and this is something we can do in 3.x a lot easier than in 2.x.

If we change how the APIS work in 2.x a lot of sites might break after upgrading.

Thats really the main reason why we ask people to either change it on their end. As an alternative they can ask for it to be changed in the next major release, which would be 3.x.

marcingy’s picture

Version: 6.x-2.x-dev » 7.x-3.x-dev

This needs to be fixed in 3.x first and then backported.

kylebrowning’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.