dir_monitor
dir_monitor copied to clipboard
berkus
Removed unnecessary converting to utf8
The boost path used wchar_t on Windows. On Czech Windows there was an error: the resulting utf8 string has odd chars, that was incorrectly converted back to wchar in boost path class.
Of course, there is: template – kopie - the long dash is the cause of problems.
Does it mean that helper::to_utf8 is working incorrectly?
The transformation should be reversible.
Of course in case of modern Windows there shouldn't be any problem in using just std::wstring, as that's the primary string type (althought it's UTF-16 not plain UCS-2).
hmmm i hadn't such problems with my russian clients (although they very like to name directories in native language). I think this issue requires additional investigation.
boost::filesystem::path use boost::filesystem::path_traits::convert() to convert std::string back to std::wstring, that use internally. I don't know what it use undercover but I think, it is a different method based on std::codecvt template. But why convert the utf16 to utf8 and then back if it is unnecessary? Independently of whether there is an error or not?
sorry, i haven't yet fully migrate to current implementation of dir_monitor.
and my local work_thread() use: impl->pushback_event(dir_monitor_event(ck->dirname, to_utf8(fni->FileName, fni->FileNameLength / sizeof(WCHAR)), type)); to process result of monitoring.
so @Vizor you are right and it's my misunderstanding :)
no, dir_monitor_event definition has been changed since https://github.com/berkus/dir_monitor/commit/e23eea204f992df94f2f62ba2329338574df50a7.
By the way, looks like we can remove helper::to_utf8 at all.
@Vizor after some investigation i have another portion of questions.
mainly: how did you reproduce current issue? how did you pass you Czech string into add_directory function?
like in my test case?
I didn´t. It come from en event, when somthing changes in monitored directory. I have recursive monitoring enabled and then a create subdirectory with the long dash in name (in monitored directory). I use async monitoring, so the wrong utf8 name come into the handler in dir_monitor_event::path.
heh next time please describe you reprodution steps right away. it will help a lot :)
@berkus i think you can close this issue.
So the previously invalid name is now handled properly by our utf16 conversion?
previous name is a valid utf8 name...
i didn't test especially Vizor's case, but i believe it must be also handled by my PR https://github.com/berkus/dir_monitor/pull/39 changes.
although.. current PR actually solves case mentioned by Vizor (appearance of subdirectories of monitored directory with non-ascii names) and my PR 39 solves case with passing non-ascii utf8-encoded string to add_directory.
Sorry guys, I was busy for a while but will get back and review the PRs.
Is there anything changed here or the code seems good to go to you?