Log paths for non-ascii account / buddy names can be too long ( > 255 characters)

[bl_beard]

(10:55:38) log: Could not create log file C:\Documents and Settings\borodin\Application Data\.purple\logs\meanwhile\%d0%91%d0%be%d1%80%d0%b8%d1%81%20%d0%92%20%d0%91%d0%be%d1%80%d0%be%d0%b4%d0%b8%d0%bd%2fFORUM\CN%3d%d0%9c%d0%b0%d1%80%d0%ba%20%d0%90%20%d0%a0%d0%be%d0%b3%d1%83%d0%bb%d1%8f%d0%ba%2fO%3dFORUM\2007-08-22.105538+0300EET.txt

(11:30:24) log: Could not create log file C:\Documents and Settings\borodin\Application Data\.purple\logs\meanwhile\%d0%91%d0%be%d1%80%d0%b8%d1%81%20%d0%92%20%d0%91%d0%be%d1%80%d0%be%d0%b4%d0%b8%d0%bd%2fFORUM\CN%3d%d0%9c%d0%b0%d1%80%d0%ba%20%d0%90%20%d0%a0%d0%be%d0%b3%d1%83%d0%bb%d1%8f%d0%ba%2fO%3dFORUM\2007-08-22.113024+0300EET.txt

[datallah]

This is happening because your username (I have no idea what it actually is, but when it is encoded, it is "%d0%91%d0%be%d1%80%d0%b8%d1%81%20%d0%92%20%d0%91%d0%be%d1%80%d0%be%d0%b4%d0%b8%d0%bd%2fFORUM\CN%3d%d0%9c%d0%b0%d1%80%d0%ba%20%d0%90%20%d0%a0%d0%be%d0%b3%d1%83%d0%bb%d1%8f%d0%ba%2fO%3dFORUM") is too long - Windows can only reliably handle paths that are less than 255 characters (amazing isn't it).

You'll notice that you can't even create a file than ends up having a path of that length with Windows Explorer.

I don't think there is a whole lot that we can do about this.

[datallah]

A workaround might be to change your settings path (according to the instructions in the FAQ) to something shorter than the default C:\Documents and Settings\borodin\Application Data\.purple.

[bl_beard]

This workaround works not always. When interlocutors ID consists of native symbols (in my case Russian, it's our corporative standard), then in 75% cases it doth not work and bug occurs again.

I think the solution is to not translate interlocutors ID into UTF-8 but leave it in original native symbols.

[rlaager]

bl_beard: The escaping here isn't UTF-8. Please try to avoid throwing around terms you don't understand.

We could write out the filename as-is (in UTF-8) instead of urlencoding it, but I'm not sure if that's kosher on all the versions of Windows we support. If it is, we're probably safe on Unix as well. If we do this, though, it more-or-less forces an incompatible transition for anyone with non-ASCII characters in their username, though.

[datallah]

One major benefit of encoding the filename is that the filenames are the same on all platforms. On Windows (except 98, which I don't really care about), Unicode filenames are fine, but on Linux, filenames are encoded according to G_FILENAME_ENCODING and G_BROKEN_FILENAMES and not necessarily UTF-8. By encoding the filename, we don't have to worry about any of this.

[bl_beard]

It's very good that it is universal and functions.

But army of users with LARGE non ASCII SAMETIME contact names have problems with saving history.

Suggest encoding method that would put symbols in ASCII without enlarging string length. For example it might be BASE64. Or any else, applicable one for similar purpouses.

[rlaager]

Replying to datallah:

One major benefit of encoding the filename is that the filenames are the same on all platforms. On Windows (except 98, which I don't really care about), Unicode filenames are fine, but on Linux, filenames are encoded according to G_FILENAME_ENCODING and G_BROKEN_FILENAMES and not necessarily UTF-8. By encoding the filename, we don't have to worry about any of this.

Of course. However, it's clear that the combination of Sametime's long names, non-ASCII characters, and URL-encoding are a problem.

We could use a more compact encoding: Punycode might be useful here.

Maybe we should add a logging preference for this that determined how we wrote the filenames? On read, we could try both names???

[bernmeister]

Should this ticket be left as is or maybe moved to Patches Welcome?

[darkrain42]

Ticket #9883 has been marked as a duplicate of this ticket.