Skip to content
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

FileStorage does not use atomic write #45

Open
JanTvrdik opened this issue Sep 3, 2016 · 6 comments
Open

FileStorage does not use atomic write #45

JanTvrdik opened this issue Sep 3, 2016 · 6 comments

Comments

@JanTvrdik
Copy link
Contributor

JanTvrdik commented Sep 3, 2016

Couple of times per month I receive unserialize error ("Error at offset X of Y bytes") from RobotLoader which uses FileStorage. This suggests that FileStorage failed to write tha data properly. I alway delete the cache which solves the issue, obviously, but it is getting quite annoying so I've decided to finally open this issue.

Windows 10 x64, PHP 7.0.8 x64 NTS, FastCGI + Caddy

@dg
Copy link
Member

dg commented Aug 18, 2017

I have never experienced such a problem.

@podolinek
Copy link

Similar bug for me, whole notice: PHP Notice: unserialize(): Error at offset 18 of 34 bytes in /project_dir/vendor/nette/caching/src/Caching/Storages/FileStorage.php:339 . It everytime occurs at the same page. Maybe some problematic string. I found this should be fixed by base64 encode/decode "hackfix" - davidwalsh blog with solution.

@milo
Copy link
Member

milo commented Jul 20, 2018

Could you post here/somewhere contents of the unserialized file? To confirm atomic access issue or serialize/unserialize bug.

@podolinek
Copy link

Well, I don't know which file is the problem. It occurs approx. once a month and tracy log only notice row to error file without any other data.

@milo
Copy link
Member

milo commented Jul 22, 2018

And how do you solve the issue? Deleting some file? Or not?

Btw, I don't think that mentioned blog solution is right. IMHO, they have some DB store/fetch issue and base64() only hides that bug.

@podolinek
Copy link

Every time "solved" by removing log file. When remove content of temp directory, no notice on problematic page created. Notice is created in random future time. Anyway, I just modified FileStorage in vendor for log variable $data on problematic page and when notice will be occurred, I will post it here. Hope it will be complete copyable content.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants