Removed unnecessary converting to utf8

[Vizor]

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.

[sbelsky]

please could you provide an example of directory naming in your case?

[Vizor]

Of course, there is: template – kopie - the long dash is the cause of problems.

[berkus]

Does it mean that helper::to_utf8 is working incorrectly?

The transformation should be reversible.

[berkus]

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).

[berkus]

Merged this to develop, keeping open for discussion though.

[sbelsky]

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.

[Vizor]

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?

[sbelsky]

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 :)

[Vizor]

It's ok, but isn't it the same function?

[sbelsky]

no, dir_monitor_event definition has been changed since e23eea2.

By the way, looks like we can remove helper::to_utf8 at all.

[sbelsky]

@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?

[Vizor]

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.

[sbelsky]

heh next time please describe you reprodution steps right away. it will help a lot :)

@berkus i think you can close this issue.

[berkus]

So the previously invalid name is now handled properly by our utf16 conversion?

[sbelsky]

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 #39 changes.

[sbelsky]

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.

[Vizor]

Ok, sorry. I thought it was obvious from the modified code.

[berkus]

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?