Sending Unicode filenames to external programs

(This thread was split from this other thread)

i don't think it's samba; it's DD-WRT v23 SP2 (09/15/06) std on the router.
i'm not sure why it's doing this, hmm...

it might (probably isn't) opus because if i try to double click a file in opus (or explorer), if notepad++ is the viewer, it will tell me that N(network drive):?????????\ doesn't exist, do you want to create directory now? But~ if i try to open that same network file with notepad.exe, it opens fine. maybe it's how certain programs see and receive filenames from network drives? some programs/components can read them fine, others see '???????'s

Programs that don't understand Unicode might see the filename as ????, or might always get the short filename instead. The setup of filetypes can also do that. Opus itself lets you choose whether to use long or short filenames in any commands which pass things to other programs, but when you doulbe-click a file it's usually the normal windows filetypes that do things.

Presumably the same thing happens with Explorer?

that's what confuses me. i know opus can understand unicode, but sometimes it seems as there is some breakdown between passing off a unicode name from a lister into a plugin or program (from a network drive) there is some problems.

i am trying to understand why sometimes the opus viewer shows a filename as 8.3. also why notepad can be passed a .txt file and open it fine, but notepad++ (another unicode program) cannot.

windows explorer can see the filenames as opus, but can successfully pass them to .. foobar2000 or notepad or wordpad.

i also just noticed that if i'm on network drive with a folder named in japanese, i cannot right click the folder and have it open a command prompt there, this only works on local drive...

maybe there is a setting that i can change in my DDWRT options, but i don't remember one like that...

How are you sending the file to Notepad++?

Can explorer send Unicode files to notepad++ in the same way?

Some of the Opus plugins still do not support Unicode, so they get passed short filenames, or just don't work (depending on exactly what happens). This is partly my own fault as I want to more or less re-write three of the plugins and that is holding up the Unicode updates.

The MP3 plugin is all Unicode though, I think. It's not one of mine though so I'm not sure and can't really say why it displays a short filename.

Do you mean you're on a UNC path, like \server\blah? If so that has nothing to do with Opus. It's a Windows limitation. You cannot open command-prompts in UNC paths. (You can use Windows PowerShell to get around this, but waiting a couple of seconds for a command prompt to open soon gets boring!)

BTW, I don't know if this applies to your exact model but this web page at least suggests that DD-WRT devices use Samba:

dd-wrt.com/wiki/index.php/Samba_Filesystem

That doesn't mean that Samba is the cause of the problems; it might have nothing to do with it. But it's often good to check whether the same problems also occur on a Windows file server as vendors don't always keep their Samba/firmware up to date, or don't always compile them for Unicode or in a way which makes file change notification work properly, etc. etc.

i right click 'open in notepad++'

[quote]Can explorer send Unicode files to notepad++ in the same way?[/quote] no, it says B:??????????\ cannot be found. regular notepad opens the file ok

[quote]Do you mean you're on a UNC path, like \server\blah? If so that has nothing to do with Opus. It's a Windows limitation. You cannot open command-prompts in UNC paths. (You can use Windows PowerShell to get around this, but waiting a couple of seconds for a command prompt to open soon gets boring!)
[/quote] i use 'map network drive' to treat harddrive on network like a local one, so that i can assign drive letters, but now that you mention it, i'm not sure if this would work either...

[quote]That doesn't mean that Samba is the cause of the problems; it might have nothing to do with it. But it's often good to check whether the same problems also occur on a Windows file server as vendors don't always keep their Samba/firmware up to date, or don't always compile them for Unicode or in a way which makes file change notification work properly, etc. etc. [/quote] maybe i can understand this soon.. @.@

i right click 'open in notepad++'

So the Notepad++ problem isn't Opus specific. You might be able to fix it with Opus, though. Go to Settings -> File Types and look at the All Files and .txt filetypes. Any context menu entries for Notepad++ in either of them?

If you can see the entry, paste its command here.

If you can't see it then Notepad++ must add the items using a context menu shell extension which I guess doesn't understand Unicode (even though Notepad++ itself does, based on what you've said). If you can configure Notepad++ not to add this entry then you can replace it with a simple command in Opus that will probably work better:

"C:\full\path\to\Notepad++.exe" {filepath$}

or, if the program can accept more than one filename at once:

"C:\full\path\to\Notepad++.exe" {allfilepath}

For what it's worth, I've replaced TextPad's right-click menu item in a similar way. TextPad adds an item that uses DDE which kept causing me problems so I nuked its context menu item and replaced it with a simple item that runs the program with the selected files as an argument. Works exactly the same way, but works better.

i can't for the life of me figure this out.. i just installed a copy of opus 9 to my desktop (this is my laptop) to see what would happen. as i thought, the viewer has an easier time playing mixed language filenames, but in the example of the mp3 viewer plugin, i still get the 8.3. i'm still trying to track out the .txt problems, too..

the code that opus was using for the .txt:
"C:\program files (x86)\notepad++\notepad++.exe" "%1"

i tried the {allfilepath} and the other one, but notepad++ just kept asking me to make a new folder at every node of the path. i don't quite understand, but i will try to use applocale on opus to see what happens

i wonder why the file name is displayed normally in the title bar of the viewer pane, but in the mp3 file name edit field it's 8.3 filename..

I've looked into this and actually installed NotePad++ to try things out.

As far as I can tell, NotePad++ doesn't support Unicode filenames at all. You can't even load them via it's File->Open menu.

I think this is an Opus problem with context menus for files.

Try making an "Open" entry for Notepad and using it to open a file with a Unicode file name. It does not work. In Explorer it does, and it does if Notepad is the default handler for .txt files.

You can usually tell if a program supports Unicode file names easily, but trying to open them with the programs own File->Open menu. For example, Firefox does not. Notepad++ seems to.

I tried making a context menu for Notepad and it worked fine with unicode paths from Opus.

On the other hand, I did File -> Open in Notepad++ and it couldn't open a file with Unicode characters even when it is the only application involved. Seems to me the problem is in Notepad++, unless I downloaded the wrong build or something.

You are right Nudel, my mistake. I had my system set to Japanese at the time.

Do you remember the problems we were having with WinRAR? How come it works this way, but not with the WinRAR context menus that work in Explorer?

aah.. i see, there is a problem with notepad++ and unicode filename. but i still can't figure out what's wrong with opus viewer and unicode mp3 over a network.. i'll keep thinking and trying and posting.

thanks for the help so far guys!

As I wrote in the other thread, I have underscores too in explorer with japanese characters at WinRAR context menus. Are you sure that your system wasn't set to Japanese at this time also? Can you please test again and double check your regional settings. Maybe a screenshot of explorer in this case is also helpful.

Regards, Norbert

my regional settings are set to english, but in vista for the most part if a program can see unicode, you will see the language that's supposed to be there. out of the box, vista can read my unicode named folders, as can opus, but on the network drives, folders named with japanese names seem to have an issue with some of thier files being played in the viewer.

the one that i am trying to figure out now is the mp3 on network drive. the viewer pane can read well the file's name--if i look at the title bar of the viewer pane (where all the controls like close, horiz/vertical, zoom) the full name of the mp3 is shown. but~ right under where the heading says 'mp3 file:' and there is a dropdown for editing the title, rate, and length, and for playing the mp3 itself. this is where i see the BLAHBL~1.MP3 truncated name.

i was wondering if the viewer pane is asking for the truncated name from the network drive, but the network drive is confused at a name that, to it, may not even exist and returns me nothing. if it's not already, could the viewer ask for the long name that's in the title bar itself in order to be able to play it?

excuse my ignorance of how the plugin works ; ;

I think the MP3 plugin just displays the short names of files for some reason. It's not specific to network drives.

It should be fixed but it doesn't seem like a big deal. The name doesn't do anything, it's just displayed, and the proper name is displayed right above it in the titlebar. (Maybe the fix should be to not display the name at all inside the plugin? :slight_smile:)

I checked, the locale was set to English when I tested WinRAR.

The correct names are displayed with the locale set to Japanese, of course, but with English it is always underscores in Opus and the correct name in Explorer.

I have East Asian Language Support installed and enabled if that helps. I imagine you do too if you can see the names at all.

Languages are a problem in Windows generally. For example, Trillian seems to support Japanese without any problems. Korean, on the other hand, just appears as squares. Korean works fine in Firefox and Notepad, just Trillian...

oh, i understand that the mp3 plugin shows the short names on local and network. what i am trying to figure out is why the short name only works for folders.. say on the desktop and not ones that are on a network drive. i dunno if the fact that the files are on the network drive is the uncommon denominator(?) that makes the viewer unable to play the mp3 or not. it just kinda made sense that if the viewer plugin is asking the network to play (when you push the play button beside the short filename) lalala~1.mp3 (no such thing on the network) instead of lalalalala.mp3 (the file's real name) then there would be the inability to play song?

so if the viewer plugin is asking the local harddrive to play lalala~1.mp3, the harddrive or os or w/e understands that 'oh, it must mean lalalalala.mp3, so let's use that one,' but over a network, that luxury isn't there and the viewer is attempting to play literally a song that doesn't really exist on network.

if i can find a floppy, i will try from there too, and usb stick to see.

but i have no idea how the plugin works or if the truncated name is what the viewer understands of the name that opus shows in the viewer's titlebar or why even it shows a truncated name at all, but none of these really matter, i'm just trying to understand why only in some cases, the same file will play from viewer from one place, and not another...

thanks for reading!

Maybe the network filesystem doesn't support short filenames, or has them turned off? What does the Short Name column in Opus show?