Closed thelaughinglama closed 1 month ago
Thanks for the very thorough bug report @thelaughinglama . I'd have to go back and look at the commits where that line was changed to make sure there change wasn't made for a very good reason.
It looks like in the past, it was escaping spaces (but that was only really valid for the local_scan
method which was all that existed in the beginning). It was presumably removed due to issues with scanning over sockets. But instead of just moving that string replacement to the local_scan
section, that part was just naively modified to remove all multiple space characters to a single space which really has no value.
I'm going to patch this issue and write some tests. I will let you know once the version with the patch is released.
The patch has been applied in v2.2.3!
Thanks for the bug report!
I got an issue while checking if a file was infected. The problem arises when the file name contains multiple consecutive spaces. The current implementation alters the input file path by replacing consecutive spaces, leading to a "Could not find file to scan!" error during the scan.
Steps to Reproduce: Attempt to scan a file with a name containing multiple consecutive spaces (e.g., "myfile name.txt"). The scan fails with a "Could not find file to scan!" error.
Expected Behavior: The SDK should correctly handle file names with multiple consecutive spaces without altering the original file path, ensuring the file can be found and scanned.
Code snippet for reference
There are a couple of ways to go about it.
.trim()
is not the same as after replacing multiple spaces.I went through the commit history for this line
file = file.trim().replace(/\s+/g, ' ');
and saw that we went fromMore information on this change would be really helpful.