Colon symbol in Directory Name

[birdman]

My $PATH variable in linux mint:

Sorry. I mis-read what you wrote.
It would be a problem (in fact, impossible) to get a directory with a ":" in its name into PATH.

However, you're not likely to want to put a directory created by Vix into PATH.

[ccs]

The only problem with a ":" in the folder name in ViX, as far as I can tell, is that selecting it in movielist returns the folder as empty.
All other operations appear to work ok.
I had debug logs on yesterday when trying it out, and there were no obvious failures being reported.

[Joe_90]

One solution is to sanitise the input to exclude the ":" and replace it with a space/hyphen/underscore. I hate seeing punctuation characters in file or directory names as it gives rise to issues of portability between various OS's. But, that's just me

[Valiant]

The sub directory name is happily created by Create Directory in the movielist Menu option but when the movielist directory is scanned the file system returns the sub directory name truncated at the offending delimiter, in my case /media/hdd/movie/Drama/Strike is returned and not /media/hdd/movie/Drama/Strike: The Cuckoo's Calling. The former obviously does not exist and the file system returns an empty list for the contents thereof, but the full path name is displayed at the top of the page. No problem with the apostrophe though. I agree with @fat-tony's suggestion that it could be trimmed by the Create Directory option, ideally prior to loading the Virtual Keyboard edit field.

[ccs]

How do you know /media/hdd/movie/Drama/Strike is returned? Surely debug logs would report an error?

When I tried using telnet, I could access folders and sub folders with ":"s without any issues.

I'd agree, something in movielist isn't quite right, but I'd been tempted to make that work rather than stripping out all potentially offending characters completely.

[simonc]

It's because everything shown in the movie list is translated from the file system using a service reference, which of course uses a colon internally as a delimiter but doesn't work terribly hard to cope with names that have colons in. This'll be the another reason for colons being stripped out of the filenames of recordings.

Fun activity: Go and look at what Windows Explorer calls your directory. I get TWUQRQ~L

[ccs]

This'll be the another reason for colons being stripped out of the filenames of recordings.

What happens if I select such a recording after the colon has been stripped, and do an epg search?

[simonc]

Don't worry. It seems to get that correct.

More interesting weirdness. This is a directory name's full service reference:

2:0:1:0:0:0:0:0:0:0:/media/hdd/TV/Documentaries/:16384%3ajpg 16384%3apng 16384%3agif 16384%3abmp

And here's that directory with the colon in the name

2:0:1:0:0:0:0:0:0:0:/media/hdd/TV/Trailblazers:16384%3ajpg 16384%3apng 16384%3agif 16384%3abmp

So the core Enigma2 code doesn't work at all well with a colon in the name of things.

[ccs]

Fun activity: Go and look at what Windows Explorer calls your directory. I get TWUQRQ~L

I see BIGKCW~L for a directory, but for a recording the colon (and dots) have been changed to underscore and the filename looks ok.

[simonc]

Found the culprit. This is run when you enter a directory to view it in the movie list:

        self.current_ref = eServiceReference("2:0:1:0:0:0:0:0:0:0:" + path)

Unfortunately, it trims off everything in your directory name after the colon, expecting it to be a pretty name for what came before the colon. Magic strings are never a good thing and this kind of nonsense is in quite a few places

If you want a quick fix, replace selCurrentRef in MovieSelection.py with this. It works for this specific scenario.

    def setCurrentRef(self, path):
        self.current_ref = eServiceReference(2, 47, path)
        # Magic: this sets extra things to show
        self.current_ref.setName('16384:jpg 16384:png 16384:gif 16384:bmp')

[Joe_90]

Just remove the friggin' ":" and replace it with a safe value before it gets included in the directory name and the problem goes away. I presume the reference to path cause the issue because path uses ":" as a delimiter.

[simonc]

Just spotted this in FileList while trawling the code for other mistakes:

# we should not use the 'eServiceReference(string)' constructor, because it doesn't allow ':' in the directoryname

Well done to the commenter in 2009, but they missed the same mistake added in 2008 further down the same file

[Joe_90]

But it probably wasn't allowing the ":" for good reason

So, what's the solution? Disallow ":" in the construction of directory names or allow ":" and verify that they are handled in all use case?


EDIT As an aside - no issue with ":" in directory name on my linux mint system. Searches work, command line works.

[simonc]

I'd argue that if you can see : in programme names in the list, you should be able to have them in directory names, especially as half the programmes in the evenings seem to start with New: on the main channels. I've got a bugfix for the erroneous code that avoids the complications of disabling : in the virtual keyboard, dealing with remotely renamed directories, directory name suggestions...

[birdman]

I'd argue that if you can see : in programme names in the list, you should be able to have them in directory names

These are, however, unrelated. One is part of a description sent by a broadcaster while the other is how a user has decided to categorize them.