Closed thomassb closed 4 years ago
@thomassb thank for using the library
two remarks:
your are indeed right about the bug and if you could submit a PR I would be glad to review it and merge it. It even breaks the PSR-16 contract 😢
the current Cache adapter provided is "optimized" for this library usage. Meaning it is highly recommended to not use it outside of the package intention and even for that I would encourage users to select a better implementation of PSR-16.
Bottom line, you can try to fix this or else I will do it when I have time but I would encourage you to not use this cache adapter outside of the current usage for which it was build for.
@thomassb I've tried to reproduce your reported bug on a linux based PHP7.4.1 but I can't reproduce it. Are you using the cache with something else that the bundle Manager class ? If so I would first review your code to be sure it's not your code at fault and I would use a more robust cache system .. as I failed to reproduce your error.
Sorry @nyamsprod seems like it's my environment. I looked through the cache code and could not find a problem I then tried to repoduce it myself on a different machine and could not. Seems like my development environment on a windows machine was not allowing modification of the cache file modified date.
This is the problem I'm having in #259
Running CentOS 7 on Vagrant with a Windows 7 Host.
Once a day the cache file is deleted so I have to manually run composer from windows to update the cache files again.
I tried increasing the cache duration to 14 days with $manager = new Manager(new Cache(), new CurlHttpClient(), '14 DAY');
, but it made no difference.
It's not a problem on remote, but still quite frustrating.
Issue summary
On getting a cache item
time() >= $expires_at
always is true.System informations
Standalone code, or other way to reproduce the problem
Expected result
'bar'
Actual result
null