#2 Non-ASCII filenames not scanned

v0.1.2
closed-fixed
General (1)
9
2010-11-23
2010-11-22
Anonymous
No

Files with non-ASCII characters in the filename are not scanned.
I think this is caused by line 277 in svs_sync_scan():
QFileInfo fileInfo(QString(path) + "/" + QString(file));

From the QString documentation:
"QString::QString ( const char * str )

Constructs a string initialized with the ASCII string str. The given const char pointer is converted to Unicode using the fromAscii() function."

To reproduce, create a directory containing a non-ASCII character such as Æ, and try to copy a EICAR test file to or from the directory. I tested on a system with UTF-8 encoding.

Discussion

  • R. Reucher

    R. Reucher - 2010-11-22

    I can confirm this issue... and yes, the bug is in svs_sync_scan() (and svs_async_scan()). I have to check for a fix... it's probably caused by QString itself, but by teh QFileInfo class it's using there. Will get back with a result as soon as I have one.

    Thanks for the report!

     
  • R. Reucher

    R. Reucher - 2010-11-22
    • assigned_to: nobody --> renereucher
    • priority: 5 --> 9
    • milestone: 1112437 --> v0.1.2
     
  • R. Reucher

    R. Reucher - 2010-11-22

    My results so far...

    QFile::exists() returns 'false' for any filename containing non-ASCII characters. As a result, QFileInfo::canonicalFilePath() returns an empty string. Both are checked for in the subsequent if (), which in the end avoids the scan...

    I've now included a non-Qt check macro (based on access() from unistd.h) in my local copy and this one correctly sees the file(name) as existing. However, I still need to find/create an alternative for QFileInfo::canonicalFilePath() as I need its functionality here...

     
  • jss2

    jss2 - 2010-11-22

    Thank you for looking into it already! (I reported the bug, but had forgotten to log in.)
    Thinking about it further: perhaps the best solution would be to avoid decoding/encoding the filename string altogether except for logging.
    The reason for this is that even if the code is fixed to use the system encoding, what happens when trying to scan or quarantine files with filenames containing (e.g.) illegal UTF-8 characters?

    QFileInfo::canonicalFilePath() can be replaced by the C library function realpath().

     
  • R. Reucher

    R. Reucher - 2010-11-22

    Well, I have to convert the strings at some point to be able to use Qt's APIs... especially because everything file-related in Qt uses QString's (according to the Qt devs, path names are internally stored as UTF-16 character strings). I probably just need to convert it _correctly_ :)...

    However, thanks for the info about realpath()... I managed to get over that point and to successfully scan such files, but a problem remains because I can't use other QFileInfo information (i. e. permissions) to cleanly quarantine that file... if this is the only solution, I have to use even more platform dependent code, which I would like to avoid. However, as this is to be used on a POSIX compliant system anyway, I _could_ do it this way...

     
  • R. Reucher

    R. Reucher - 2010-11-22

    OK, I think i found the right solution -- in the end it was easy :). I had to setup the text-codec for C-string conversion to the current locale's text-codec, and this fixed it (at least for me). The fix is in SVN.

    I'll await your test results before I close this issue. If it fixes it for you as well, I'll release a new version soon...

     
  • R. Reucher

    R. Reucher - 2010-11-22
    • status: open --> open-fixed
     
  • jss2

    jss2 - 2010-11-23

    Thanks, it works for me now. Filepaths containing illegal UTF-8 characters are not scanned though, but perhaps that's a small problem in practice.

     
  • R. Reucher

    R. Reucher - 2010-11-23

    Well, that's probably not a problem at all... meaning that if they are "illegal", they shouldn't be used.

    Thanks for testing!

    I'll close the issue then and will likely release a new version on Thursday (I have no time right now due to my "real" work).

     
  • R. Reucher

    R. Reucher - 2010-11-23
    • status: open-fixed --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks