bugGNU Octave - Bugs: bug #44103, Can't open a folder that contains...

 
 

bug #44103: Can't open a folder that contains special characters

Submitter:  Lutz Mager <rocketsound>
Submitted:  Wed 28 Jan 2015 11:43:10 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Duplicate Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 3.8.2 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 05 Sep 2016 12:38:52 AM UTC, comment #13: 

I think that this bug has not been fixed yet but duplicated to the bug #42036.
Therefore correct status is duplicated but not fixed.

Tatsuro MATSUOKA <tmacchant>
Tue 10 Feb 2015 06:05:35 AM UTC, comment #12: 

Yes, the gui can handle unicode characters in file names, but what about octave itself? In the command window (gui and cli) it is not possible to enter special characters and existing directories with special characters are not shown correctly (like in 'pwd' as mentioned by Rik's comment #7).

Torsten Lilge <ttl>
Group Member
Tue 10 Feb 2015 12:30:12 AM UTC, comment #11: 

I believe Qt is Unicode. Looks like the terminal is processing data as Unicode, however we call QTextCodec::setCodecForCStrings (QTextCodec::codecForName ("UTF-8")) in octave-gui.cc, so would be getting multiple bytes for some characters ? which we might not be handling correctly.

John Donoghue <lostbard>
Group Member
Mon 09 Feb 2015 09:14:38 PM UTC, comment #10: 
Torsten Lilge <ttl>
Group Member
Mon 09 Feb 2015 09:09:33 PM UTC, comment #9: 

I'm adding John D. to the CC list.  He seems to have the most experience with MXE and can tell whether we are doing an ANSI or Unicode build of the terminal.  Hopefully he can also tell us whether this is an easy thing, or something to forget about unti release 4.2.

Rik <rik5>
Group administrator
Mon 09 Feb 2015 08:56:05 PM UTC, comment #8: 

Am I right that the mxe build for windows is an ansi, not an unicode build? I guess this is the cause for the remaining oddity (which can be seen in the cli version, too) and also for bug #43099.

Torsten Lilge <ttl>
Group Member
Mon 09 Feb 2015 04:54:09 PM UTC, comment #7: 

@Torsten: Your patch works on Windows 7 so it should be applied and then this bug can be closed.

There remains one oddity.  The Terminal in the Command Window is not running Unicode so 'pwd' produces a strange set of symbols for a directory with special characters even though the name displays correctly in the File Browser.

Rik <rik5>
Group administrator
Sun 08 Feb 2015 05:41:36 PM UTC, comment #6: 

I don't think there's any reason to support XP, it's just the virtual machine I have available for testing.  I'll have to borrow another computer with Win 7 to test this.

Rik <rik5>
Group administrator
Sun 08 Feb 2015 02:02:18 PM UTC, comment #5: 

Does Win XP use Unicode encoding per default? If not, should we still support XP?

Torsten Lilge <ttl>
Group Member
Tue 03 Feb 2015 09:42:07 PM UTC, comment #4: 

The patch doesn't work for me.  This is on an old Windows XP OS running in a virtual machine.  See the attached screenshot which shows me trying to use the File Browser to descend into a directory with "a umlaut" and "o umlaut" in the name.  The name is displayed correctly in the File Browser, but not in the terminal.


Rik <rik5>
Group administrator
Tue 03 Feb 2015 07:14:49 PM UTC, comment #3: 

@Torsten: I'm building mxe-octave to test this.  I'll let you know in a few hours.

Rik <rik5>
Group administrator
Sun 01 Feb 2015 01:43:57 AM UTC, comment #2: 

I can't do that right now as I'm to inexperienced; I've never made a build by myself yet.

Lutz Mager <rocketsound>
Thu 29 Jan 2015 07:58:50 PM UTC, comment #1: 

Thank you for the report. I have attached a patch that solves the issue on my Win 7 system. Are you able to make a patched mxe-build for testing?


(file #32944)

Torsten Lilge <ttl>
Group Member
Wed 28 Jan 2015 11:43:10 AM UTC, original submission:  

I hope this bug report isn't redundant, since I feel it might be related with bug #43099.

If you try to open a folder that contains special characters like ä, ö, ü an error like


error: C:/Users/Lutz/Documents/MATLAB/FMKS/Übung 11: No such file or directory


is thrown.

Some further observations:
1) You need to STRG+C on the terminal, since the error won't "return" the input to the user.
2) Also, after canceling you will notice that the current directory didn't change but the file browser (i.e. pwd/the current directory and the file browser get out of sync).
3) After the file browser got out of sync (see point 2) you can try to open a file and will get big error message


HDF5-DIAG: Error detected in HDF5 (1.8.10) thread 0:
  #000: /home/benutzer/mxe-octave/tmp-hdf5/hdf5-1.8.10/src/H5F.c line 854 in H5Fis_hdf5(): unable to open file
    major: Low-level I/O
    minor: Unable to initialize object
  #001: /home/benutzer/mxe-octave/tmp-hdf5/hdf5-1.8.10/src/H5FD.c line 987 in H5FD_open(): open failed
    major: Virtual File Layer
    minor: Unable to initialize object
  #002: /home/benutzer/mxe-octave/tmp-hdf5/hdf5-1.8.10/src/H5FDsec2.c line 362 in H5FD_sec2_open(): unable to open file: name = 'C:/Users/Lutz/Documents/MATLAB/FMKS
/Übung 11/matlab2tikz.m', errno = 2, error message = 'No such file or directory', flags = 0, o_flags = 0
    major: File accessability
    minor: Unable to open file


4) Even the "Change Directory or Add Directory to Load Path" dialog that pops up can't move into such directories (for both cases: either adding the directory to the path or changing the current directory fails).

I only tested this on Windows 7 64-Bit.

Lutz Mager <rocketsound>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #32989:  umlaut_chdir.png added by rik5 (76KiB - image/png)
file #32944:  bug_44103_p1.diff added by ttl (854B - text/x-diff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by siko1056 (Updated the item)
  • -email is unavailable- added by tmacchant (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by ttl (Updated the item)
  • -email is unavailable- added by rocketsound (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-22 siko1056 StatusFixed Duplicate
    2015-02-09 ttl StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2015-02-09 rik5 Carbon-Copy- Added lostbard
    2015-02-03 rik5 Attached File- Added umlaut_chdir.png, #32989
    2015-01-31 rik5 Item GroupSegfault, Bus Error, etc. Incorrect Result
    2015-01-29 ttl Attached File- Added bug_44103_p1.diff, #32944
        StatusNone Patch Submitted

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code