And unsure how to troubleshoot or reliably replicate it. 1.1.5 install. If there are any attachment errors, post data is lost. Yes, an error message is provided (example file stat something or other). Also yes, a draft is saved, but that isn't obvious to an average user. It would be desirable for post text to succeed regardless of attachment errors. Users may always edit to attempt attachment issue correction. It would be instinctive in the event of an attachment failure.
Anyway, does anyone have troubleshooting suggestions? Thanks!
hmm... can you post a screen of the error please?
Be glad to, if I can catch it in the act again. Oh, the filesize error displays filepath info as well. Not sure that's a good thing either if normal users can see it.
Here is the error:
filesize(): stat failed for /var/www/web.....
..
I thought I mentioned this in another post where the fix was missed? Or is it another bug?
Good question. I recall something similar. All Elk code is current. Error aside, it isn't desirable losing post text in the event of an attachment error.
Nope. Not mind but
@radu81 did report this (relating to file based caching?) at: https://www.elkarte.net/community/index.php?topic=5204.0
Hhmm....in full disclosure, the setup uses php 7.3 (though it occurs when falling back to 7.0), opcache, apcu, nginx 1.15.5, mariadb 10.3.10
Could you get a copy of the file that the user is trying to upload (the one that causes the attachment error)
The filesize() error just means its trying to get the size of a file that, for one reason or another, did not "make it" to the server. You also use the attachment image resize addon? So that could be in play here as well.
It's happened to me. Sometimes the second attempt is successful. Yes, I use the resize addon.
I'm still experiencing this issue. It's unfortunate there isn't more information to report, yet. It simply seems to occur at random. The same image may fail a couple or three times, then inexplicably decide to work. Ideas? What needs to be checked?
I keep checking on this as I really think it has something to do with the attachment resize addon .... I just have not come across the right set of conditions :( ... but it really has to be something in that addon (and why I just want to make it part of the core in 2.0 since it has to kind of "hot wire" the attachment code to work right now.
Something to look at, thanks!
Due to the sporadic nature of the error, this isn't 100% proven. Anecdotal observation suggests this happens when using the inline image functionality in conjunction with image resizing mod. Just to include more possible troubleshooting info.
Well I'm finally using the AIR addon on a live 1.1.6 and its a bug for sure in the resize code.
I've tried a couple of fixes, hopping it would be easy, but same error is occurring. I think it is a sort of race condition caused by the displaying of the little icon in the post panel, to get that it has to pass the resize code before the post and something is not done or cleared after that such that when you hit post and it does it again, it sometimes goes boom!
Well at least you know you were not crazy, well about this bug at least ;)
Quite certain I was, and still am, a bit off the mark. ;D
Cool, at least it's a step in the right direction. Many thanks Spuds!
OK who's ready for a test ...
Replace your current file in the subs directory with this one and lets see what happens.
The previous resize code was triggered during the ulattach operation, that is the action that creates the icon/thumb images shown in the post attachment area. This update skips that action and should only run when the user actually posts. So if we did have a race condition or some file lock contention, then this should fix that. hopes
Testing will tell !
The patch has been loaded on my 3 sites and released to the wolves. A couple of quick test uploads gave affirmative results. Will check in again with further results! Many thanks Spuds!! You da man!
Thanks for putting this to the test :D you da man and I appreciate the effort..
A few days have passed while a few dozen images have been uploaded. So far there are no related errors in the log, and no reports of failed uploads. Seems logical the fix is good! Thanks again Spuds!
Great to hear
I've also been beating on it with multiple large (10mb) files and only had a single hit in the error log, so I feel my assumption about what was occurring was correct. I intend to do another look at exactly where the absolute best place is to run (meaning on the first attach action or the actual post action) but for now at least we have a direction to refine.
Thanks again for the testing!
This thread deserves an update. Several months have floated by. The world has been a rollercoaster. Our lives have been impacted by a virus "they" say originated from an old bat, though it's unclear how Nancy Pelosi could be involved.
Spuds, your work definitely improved the situation. However, the error still occurred on occasion. Strangely, it seemed most prominent when attaching smaller file size images. Odd for sure. And zero predictability regarding the phenomenon.
Then through unrelated tinkering I discovered the likely root cause. nginx directio does not play well with inlining attachments. If you use nginx it is probably best to turn directio OFF. At least that is the current supporting information. Time will tell.....
.....if anyone has other advice let's hear it!