File upload stopped working after updating to 2.1.0

Solution to anyone also affected. Downgrade to 2.0.3 and everything immediately starts to work again

@klemendev - here's a bit of specifics

• 2.0 is using deprecated hook → .
• 2.1 is using new recommended EventSubscriber method which should work on 10.3+

I tested it on 11.0 and 11.1 but haven't thoroughly tested it on 10 branch.
In the meantime I would like you to provide the logs and if you can answer the following

• Does it timeout or gives you an error?
• Does it connect to ClamAv?
• Does it work when you set Allow unchecked files?

I'll downgrade it to major until we have concrete evidence or at least two references that the module does not work in 10.4

I'll test it in 10.4 in the meantime. Cheers.

Just retested it thoroughly on 10.4.1. All works

• Settings: Bad daemon connection, Block unchecked files. Result: file is blocked
• Settings: Bad executable file, Block unchecked files. Result: file is blocked
• Settings: Good executable file, Block unchecked files. Result: file is uploaded
• Settings: Bad executable file, Block unchecked files. Result: file is blocked
• Settings: Bad executable file, Allow unchecked files. Result: file is uploaded

I need someone else to test it for me. Dropping it to normal until more results are

In the meantime I would like you to provide the logs

The problem is nothing is logged, it just doesn't work and gets stuck. Even enabling verbose logging does nothing, it just gets stuck when uploading a file. I have logging redirected to syslog and it is confirmed to work.

Does it timeout or gives you an error?

If I select a file from the computer, file just remains selected but never uploads. No error is shown to the user, it just sits there in the "file chooser form element" and loading bar or throbber (depending on setting) is shown. Then after a few minutes, loading indicator disappears but the file is still not uploaded. Nothing is logged, even with verbose logging on.

Does it connect to ClamAv?

I think so. If I change the unix socket path to something that is not valid, the upload terminates with the following message:

The anti-virus scanner could not check the file, so the file cannot be uploaded. Contact the site administrator if this problem persists.

It also logs that clamav can't be accessed to syslog.

If the path is fixed back to a valid unix socket path, the infinity upload without error behavior comes back.

Does it work when you set Allow unchecked files?

No. Selecting "Allow unchecked files" does not change the behavior of the issue.

---------

I don't know the internals of the module so I can't debug myself, but I can place some debug prints in sections of the code as instructed and can provide what parts of the code are reached if this can somehow help.

Thank you @klemendev for all the information.
If selecting "Allow unchecked files" does not change the behaviour of the issue suggest that there are some issue with setup.
Do you have access to ClamAv logs?

If selecting "Allow unchecked files" does not change the behaviour suggests that there are some issue with setup

I would also usually suspect this, but what sort of disproves this theory is that downgrading to 2.0.3 immediately fixes the problem.

Are there any differences in how 2.0.3 communicates with ClamAV via the Unix socket compared to 2.1.0?

Do you have access to ClamAv logs?

Yes, I do. I have checked logs and in the time interval when I was doing tests with 2.1.0, nothing unusual was logged.

@klemendev no difference in communication.
The goal of the release was to replace hook_file_validate with event subscriber as per change record → instructions.

Do you have xDebug setup on your machine?

I don't have xDebug installed unfortunatelly. I have added some debug logs and found out the line where it hangs, it is DaemonUnixSocket.php, this line:

$response = trim(fgets($scanner_handler));

So basically on 2.1.0, when file is uploaded, the upload process on the form gets stuck on this line.

I have checked 2.0.3 to 2.1.0 diff and indeed here nothing was changed, yet on 2.0.3 it works flawlessly and as soon as I update to 2.1.0, it gets stuck when uploading the file. It seems fgets call never returns.

Since scanning logic didn't change, could it be that there is some "contextual" or threading difference between the old hook and new event subscriber that could cause this? I have done some searching and it seems fgets may not play well in a multi-threaded environment (and e.g. multiple users uploading files at the same time). It could be a complete shot in the dark, I have very little experience with PHP and streams.

More testing has been done.

Even if I switch from a Unix socket to a TCP connection, the same thing happens.

In 2.0.3, both socket and TCP connection work, in 2.1.0, the upload simply hangs and file is never uploaded to the website

Thanks @klemendev for details and testing.
Anyone else having similar issues?

With 800 sites using 2.1.0 and no one else joining this report, seems this is not a widespread problem.

Does anyone have any ideas on what else I could try or how to debug this problem further?

Another update on my side. I have added this code snippet to the Unix socket scanner:

$file_size = filesize($file->getFileUri());
\Drupal::logger('ClamAV')->error('Size of file is: ' . $file->getSize() . ', URI is: ' . $file->getFileUri() . 'file size is: ' . $file_size);

When uploading a test file (PNG), on 2.0.3, I get this log:

Size of file is: 387365, URI is: /tmp/phpzipzoEfile size is: 387365

When uploading this same file on 2.1.0, I get this log:

Size of file is: 387365, URI is: /tmp/phpuX8xcsfile size is: 506707

It appears there is a difference between file sizes for some reason. The correct uploaded file size is 387365.

It seems that getFileUri() in 2.1.0 points to the wrong file, as it has a different file size.

Is there a chance the new event subscriber does not work the same as the old hook and does not fire at the same time in the file upload process as before? Therefore the file passed to the Scanner is not written yet/does not exist/has the wrong size?

Asked on the Slack in #contribute.

Seems this module is not using the right event. The one currently used is for altering validation constraints, not for adding new one (source: https://www.drupal.org/project/drupal/issues/3506242 🐛 FileValidationEvent is not drop-in replacement for hook_file_validate Active - #3)