| Time |
Nickname |
Message |
|
15:02
π
|
Nemo_bis |
How am I supposed to deal with filenames containing a slash under Windows? https://code.google.com/p/wikiteam/issues/detail?id=86 |
|
15:22
π
|
Dud1 |
Not sure if it's a bug or not, but if I start a dump on the desktop then move it to say my documents, when I try start it again it says it can't find hte config file (even though it is there). |
|
15:33
π
|
Nemo_bis |
Dud1: resume is a bit silly, it fetches some data it should not including (probably) the full path |
|
15:33
π
|
Nemo_bis |
feel free to file a bug for this |
|
15:47
π
|
Dud1 |
Okay I will when I get home |
|
22:55
π
|
danneh_ |
Nemo_bis: Either just make the folder and throw the picture in there (so in that example, 'Engelsk' folder would be made, and 'Norsk.png' would be put under it. Fairly easy to implement in py |
|
22:56
π
|
danneh_ |
Or we could change / to another character and note it in a filenamechanges.txt / rewrite the history file ourselves |
|
22:57
π
|
danneh_ |
Huh, mac allows / in folder names, never knew that |
|
22:57
π
|
danneh_ |
Silly mac |
|
23:00
π
|
Nemo_bis |
dir is ugly |
|
23:00
π
|
Nemo_bis |
checking for illegal characters manually even uglier |
|
23:01
π
|
danneh_ |
I think we can group those into one sentence: Windows is ugly |
|
23:01
π
|
Nemo_bis |
sure :) |
|
23:01
π
|
danneh_ |
Then again, '/' in filename would screw up Linux boxes too :P |
|
23:01
π
|
Nemo_bis |
hopefully there's some library which does "ohnoes we're on windows" and then goes "ok this nice filename must be translated to this other" |
|
23:02
π
|
Nemo_bis |
never heard of problems from linux users |
|
23:03
π
|
danneh_ |
I'm fairly sure it'd still fail for them. That 'No such file or directory' also occurs when the parent directory (images/Engelsk in this case) isn't found |
|
23:04
π
|
danneh_ |
probably just not too many wikis with slashes in filenames, because it's crazy |
|
23:07
π
|
danneh_ |
hmm, if it's not a valid filename we could always create a base64 folder inside the images folder, base64 the original file name, dump it in there and make a note of the original filename -> base64 name in a testfile |
|
23:08
π
|
danneh_ |
a bit ugly, but base64 is probably the easiest way to slugify the filenames and let people more easily get them back _|o|_ |
|
23:10
π
|
danneh_ |
and then we could always leave an unbase64.py script either in the main directory or just in wikiteam google code, for people to run once they get on an appropriate platform (that un-base64s them and sticks them back in the main images directory instead) |
|
23:10
π
|
danneh_ |
or something along those lines, perhaps |
|
23:10
π
|
danneh_ |
unfortunately, cross-platform filenames are annoying >_> |
|
23:11
π
|
Dud1 |
There wouldn't be that many people using it on windows would there? |
|
23:21
π
|
danneh_ |
Hopefully not |
|
23:22
π
|
Nemo_bis |
ugh base64 |
|
23:23
π
|
Nemo_bis |
If it can also be used for the filenames we currently have to truncate, I'd be happier to try it |
|
23:32
π
|
danneh_ |
ah, fair enough |
|
23:32
π
|
danneh_ |
I'll take a look and see what I can cook up |
|
23:38
π
|
danneh_ |
if we were doing truncated, it'd probably be best to go with some cryptographic hashing algorithm instead (to minimise the change of collisions Γ’ΒΒΓΒ especially when truncated filenames are in play), one of the SHAs or something |
|
23:38
π
|
danneh_ |
something already in py, hopefully |
|
23:47
π
|
Nemo_bis |
hopefully |