-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
[Bug]: unhandled exception in ExifProvider crashes scan run #35931
Comments
The issue is here:
|
We're also experiencing this. It triggers when uploading via the web ui or via webdav. |
The same problem here after update from 24.x to 25.0.4 and 25.0.5 and uploading images from Android device with the app “folder sync”: With version 24.x there was no problems.
Reading line 71: https://github.com/nextcloud/server/blob/873501a141c3ddfc3d8ce4291123a7a2842ece8e/lib/private/Metadata/Provider/ExifProvider.php 1 $file->getContent() is boolean (maybe false) instead of an expected string (path with filename). External storage support 1.17.0 is used and the access is realized by SFTP. In activity log, image is created then deleted. The folder sync app try it again, create and then delete. The maintainer of the Folder Sync app can't fix the problem. He tolds, that's realted to the NextCloud Server. |
I believe I'm hitting this (or a very related) bug as well. I've uploaded a bunch of data (few TB) and then wanted to run a scan. So when I've finished all file copying, I ran the command:
That went fine across first ~30% of data, then started stalling on files with errors such as:
I thought my permissions were bad, then started thinking my file copy was corrupted, and started to delete.. well.. a lot of data sadly (will need whole day tomorrow to copy it back). Then at some point I've noticed it's just too much, and it can't all be corrupted, tried shortening my paths, excluding spaces, and such, then finally tried opening files as Anyway, long story short...
Note that it actually fails on the very first file it finds, and if I delete that file manually it will just do the same for next one and next and next. But (!!) if you first do a full scan without metadata, eg.:
... that scan works fine!
... ending with...
I can only cry myself to sleep about not finding the workaround sooner, now I "only" have to repeat copying 6 years of video recordings... but hopefully this comment helps finding a bug. Btw, I haven't yet actually checked if metadata is indeed imported with the subsequent scan, but scanning same folder (single year of data) shows that scan without metadata ends with
while scan with metadata lasts much longer (and I can visually say it scans slower on JPG files)
Edit:
|
Finally had some more time to go through old log files. I've found three slightly different occurances of this error, as mentioned in OP, all include 1
2
3
|
Still present in Nextcloud Hub 3 (25.0.6) |
This one should be fixed by #37943 |
So, I looked into it and apart from the TypeError, this behavior is on purpose. getimagesizefromstring does not throw on errors, it triggers PHP errors, it’s a design choice of the scan command to convert that into an exception. This is why there is not try/catch on the call. That said, I opened a PR to show errors but continue, let’s see what others think of this change. |
Problem still present in 26.0.2 and 26.0.3rc2 |
Can confirm the issue persists with 26.0.2 |
This is not the same problem, it is not about files:scan stopping at first error. @Ramblurr The fix for this is in #37944 which is included in 26.0.2, so I doubt that you see the same behavior described here on this version? |
Have applied as workaround (until v27 is available) this patch from master and it's working now. [https://github.com/nextcloud/server/commit/997efe44ffd56959f198be2e3aa71687a2f11412](url) |
Bug description
When doing a full file scan incl metadata generation, any file that trips the
getimagesizefromstring(...)
call in theExifProvider
will make it throw an exception that is handled so late that it crashes the whole scan run.getimagesizefromstring(string $string, array &$image_info = null): array|false
behaves likegetimagesize(string $filename, array &$image_info = null): array|false
in that it will throw Errors under certain circumstances. However, the call to this function isn't wrapped in a try/catch (see here and here)Steps to reproduce
occ files:scan --generate-metadata
against, for example, a 0 byte file (or a file that has a header that looks malformed to that function.Expected behavior
Don't crash the whole scan run - ignore the file, maybe log a warning, and move on to the next one.
Installation method
Community Docker image
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.1
Web server
Nginx
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Fresh Nextcloud Server install
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
No response
Additional info
No response
The text was updated successfully, but these errors were encountered: