Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#2 Non-ASCII filenames not scanned

v0.1.2
closed-fixed
R. Reucher
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