Skip to content

[Cache] Set mtime of cache files 1 year into future if they do not expire #45029

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

Closed
wants to merge 0 commits into from

Conversation

Blacksmoke16
Copy link
Contributor

Q A
Branch? 4.4
Bug fix? yes
New feature? no
Deprecations? no
Tickets -
License MIT
Doc PR -

#26127 made is so that 0 is used to represent cache files that do not expire. However this was causing touch to be called with 0, which was setting the create/modification time of the file to start of epoch time, which doesn't really make sense. It can cause some issues with tar for example as when timezones are taken into consideration you end up with warnings like:

tar: app/cache/prod/annotations/@/+/3/cdcAWwqaPORAi0TfsO5Q: implausibly old time stamp 1969-12-31 19:00:00

Given the expiration of the files is stored within the file itself, it's probably safe to not touch it if that value is 0. However is there actually a reason to touch it at all as a file that expires in 6 hours would show as created 6 hours into the future.

I also wasn't sure how to test this, so open to suggestions on that/if we need the touch at all.

@carsonbot
Copy link

Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

  • Always add tests
  • Keep backward compatibility (see https://symfony.com/bc).
  • Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
  • Features and deprecations must be submitted against the 6.1 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

@carsonbot carsonbot changed the title Do not set modtime of cache files if they never expire (are 0) [Cache] Do not set modtime of cache files if they never expire (are 0) Jan 14, 2022
@Blacksmoke16 Blacksmoke16 changed the title [Cache] Do not set modtime of cache files if they never expire (are 0) [Cache] Set modtime of cache files 1 year into future if they do not expire (are 0) Jan 14, 2022
@nicolas-grekas nicolas-grekas changed the title [Cache] Set modtime of cache files 1 year into future if they do not expire (are 0) [Cache] Set modtime of cache files 1 year into future if they do not expire Jan 18, 2022
@nicolas-grekas nicolas-grekas changed the title [Cache] Set modtime of cache files 1 year into future if they do not expire [Cache] Set mtime of cache files 1 year into future if they do not expire Jan 18, 2022
@nicolas-grekas
Copy link
Member

Thank you @Blacksmoke16.

nicolas-grekas added a commit that referenced this pull request Jan 18, 2022
…y do not expire (Blacksmoke16)

This PR was squashed before being merged into the 4.4 branch.

Discussion
----------

[Cache] Set mtime of cache files 1 year into future if they do not expire

| Q             | A
| ------------- | ---
| Branch?       | 4.4
| Bug fix?      | yes
| New feature?  |no
| Deprecations? | no
| Tickets       | -
| License       | MIT
| Doc PR        | -

#26127 made is so that `0` is used to represent cache files that do not expire. However this was causing `touch` to be called with `0`, which was setting the create/modification time of the file to start of epoch time, which doesn't really make sense. It can cause some issues with `tar` for example as when timezones are taken into consideration you end up with warnings like:

> tar: app/cache/prod/annotations/@/+/3/cdcAWwqaPORAi0TfsO5Q: implausibly old time stamp 1969-12-31 19:00:00

Given the expiration of the files is stored within the file itself, it's probably safe to not `touch` it if that value is `0`. However is there actually a reason to touch it at all as a file that expires in 6 hours would show as created 6 hours into the future.

I also wasn't sure how to test this, so open to suggestions on that/if we need the `touch` at all.

Commits
-------

57cad6f [Cache] Set mtime of cache files 1 year into future if they do not expire
@Blacksmoke16 Blacksmoke16 deleted the cache-file-mod-time branch January 18, 2022 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants