bugGNU Octave - Bugs: bug #55161, Cannot open multiple files from...


bug #55161: Cannot open multiple files from Google Drive File Stream in the editor

Submitted by:  Christos Sevastiadis <csevast>
Submitted on:  Tue 04 Dec 2018 10:50:17 AM UTC  
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  Kai Torben Ohlhus <siko1056>
Originator Name:  Open/Closed:  Closed
Release:  5.1.0 Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sat 04 Jan 2020 04:24:48 AM UTC, comment #30: 

Marking as Fixed and closing report.

Rik <rik5>
Project Administrator
Wed 30 Oct 2019 08:49:14 PM UTC, comment #29: 

I confirm that it works.

Great work!

Thank you very much for your effort.


Christos Sevastiadis <csevast>
Mon 28 Oct 2019 11:48:02 PM UTC, comment #28: 

On 10/29/19 4:49 AM, Matt Wheeler wrote:

> It works! Wow, changed my life (work life). :-)
> Thank you all!

Please use the Savannah bug tracker to answer.

Happy to hear this.  This change will be part of whatever will be the next official release of Octave.

Kai Torben Ohlhus <siko1056>
Project MemberIn charge of this item.
Mon 28 Oct 2019 11:08:37 AM UTC, comment #27: 

Especially Christos Sevastiadis and Matt Wheeler, can you confirm using my installer, that this resolves your problem?

Kai Torben Ohlhus <siko1056>
Project MemberIn charge of this item.
Mon 28 Oct 2019 11:07:00 AM UTC, comment #26: 

Pushed: https://hg.savannah.gnu.org/hgweb/octave/rev/3b50efa29be4

If anyone else wants to test, for a while you can download this build at your own risk:


For me this patch resolves the OPs problem and _run_test_suite_ worked.

Leaving this report open, until some other MS Windows maintainer gives his okay.

Kai Torben Ohlhus <siko1056>
Project MemberIn charge of this item.
Sat 26 Oct 2019 09:15:22 AM UTC, comment #25: 

Agree.  Sure, I can prepare and push a patch on Monday for it (then I got my MS Windows 10 system for final regression testing again).  I also vote to push it to stable. The OP almost waits one year for his GStream setup to work <joke>he didn't pay us to make it happen faster</joke> ;-)

Kai Torben Ohlhus <siko1056>
Project MemberIn charge of this item.
Fri 25 Oct 2019 06:41:41 PM UTC, comment #24: 

Agreed. Kai, could you please prepare a patch and push it?

We should consider to push this into the stable branch.

Torsten Lilge <ttl>
Project Member
Fri 25 Oct 2019 06:30:20 PM UTC, comment #23: 

If stat works as well, that would simplify the code significantly.

A direct link to what C++17's "equivalent" would do(?):

The note might give the reason why we have OS specific code:

> Windows implementations may use GetFileInformationByHandle() as a surrogate for stat(), and consider "same" to be equal values for dwVolumeSerialNumber, nFileIndexHigh, nFileIndexLow, nFileSizeHigh, nFileSizeLow, ftLastWriteTime.dwLowDateTime, and ftLastWriteTime.dwHighDateTime.

So Kai's patch is probably the safest thing to do until we switch to using C++17.

Markus Mützel <mmuetzel>
Project Member
Fri 25 Oct 2019 05:36:06 PM UTC, comment #22: 

I agree to use Kai's patch to fix this.

However, one post of the thread on stackoverflow linked to in comment #20 mentions using stat () and comparing various elements of the resulting structure. If this works, this might be a solution without special windows API code.

Torsten Lilge <ttl>
Project Member
Tue 15 Oct 2019 09:45:35 AM UTC, comment #21: 

canonicalize_file_name doesn't necessarily give the same result on Windows when it comes to case sensitivity and short paths (8.3 names). Additionally, it doesn't work for UNC paths IIRC. (I came across this in bug #56267.)
There is an initial patch for the former issues in bug #56267.

Maybe a work-around would be to check whether the path started with "\\" and use the current code path. And call (a fixed) canonicalize_file_name otherwise before comparing.
But that would introduce an additional code path we need to maintain.

Long story short: I think the best solution atm would probably be to fix same_file_internal with the additional comparisons as Kai suggested.
The reason why we have Windows specific code there in the first place is non-ASCII characters and the Windows file API needs special handling (even gnulib's fstat replacement doesn't work).

Markus Mützel <mmuetzel>
Project Member
Tue 15 Oct 2019 06:39:03 AM UTC, comment #20: 

Alright, I attached the file with the working check as mentioned in comment #18

retval = (hfi1.dwVolumeSerialNumber == hfi2.dwVolumeSerialNumber
          && hfi1.nFileIndexHigh == hfi2.nFileIndexHigh
          && hfi1.nFileIndexLow == hfi2.nFileIndexLow
          && hfi1.nFileSizeHigh == hfi2.nFileSizeHigh
          && hfi1.nFileSizeLow == hfi2.nFileSizeLow
          && hfi1.ftLastWriteTime.dwLowDateTime == hfi2.ftLastWriteTime.dwLowDateTime
          && hfi1.ftLastWriteTime.dwHighDateTime == hfi2.ftLastWriteTime.dwHighDateTime);

The reason for this Windows API code to be used might be, that it is sponsored 2009 by StackOverflow to address those many absurd ways of specifying case insensitive, abbreviated, ..., paths in MS Windows:


Torsten, your suggestion is to rely on the canonical path only to check for equality?  I was fine with it, the alternative by "GetFileInformationByHandle" is error prone too, as shown by this bug report.

(file #47672)

Kai Torben Ohlhus <siko1056>
Project MemberIn charge of this item.
Tue 15 Oct 2019 05:41:42 AM UTC, comment #19: 

Kai, thanks for testing and for isolating the issue with same_file.

Im am wondering why this windows API specific code is used here and whether it might be possible to use sys::canonicalize_file_name () before comparing the file paths.

Torsten Lilge <ttl>
Project Member
Tue 15 Oct 2019 05:35:04 AM UTC, comment #18: 

I think a possible solution is to really compare ALL fields of the struct returned by "GetFileInformationByHandle", as suggested by boost


and what will became a function in C++17


Kai Torben Ohlhus <siko1056>
Project MemberIn charge of this item.
Tue 15 Oct 2019 04:42:28 AM UTC, comment #17: 

To investigate the problem, I created file #47671 (main.cc) to not always have to compile mxe-octave again.  The problem is, that for the "google file stream" the MS Windows "fileapi.h" function "GetFileInformationByHandle" cannot extract the fields

hfi1.nFileIndexHigh  == 0
hfi1.nFileIndexLow   == 0

That is

$ gcc main.cc
$ ./a.exe
    * same_file (1): f1 = C:\Octave\myfile.m *
    *                f2 = C:\Octave\myOtherFile.m *
    * same_file (2): hfile1 is valid *
    * same_file (3): hfile2 is valid *
    * same_file (X):  1646825395 1646825395 1900544 1572864 268690 268700 *
    * same_file (4): retval = 0 *

$ gcc main.cc
$ ./a.exe
    * same_file (1): f1 = H:\My Drive\myfile.m *
    *                f2 = H:\My Drive\myOtherFile.m *
    * same_file (2): hfile1 is valid *
    * same_file (3): hfile2 is valid *
    * same_file (X):  428019990 428019990 0 0 0 0 *
    * same_file (4): retval = 1 *
    * same_file (5): VolSerialNo equal: 1 *
    * same_file (6): nFIndexHigh equal: 1 *
    * same_file (7): nFIndexLow  equal: 1 *

There is another function "GetFileInformationByHandleEx", notice the "Ex" suffix.


Is there any experienced MS Windows developer to enlighten us? ^^

Kai Torben Ohlhus <siko1056>
Project MemberIn charge of this item.
Tue 15 Oct 2019 03:00:44 AM UTC, comment #16: 

Thank you for the patch.  I managed to build a recent stable mxe-octave version with your patch (file #47662) applied.  If anyone else wants to test, for a while you can download this build at your own risk:


The testing setup was as follows:

H:\My Drive\myfile.m
H:\My Drive\myOtherFile.m

with both first line "sombrero ()" and "myOtherFile.m" with a second line 'disp ("Hi")'.

The test run (in Octave GUI) consists of:

edit myfile.m
edit myfile.m
edit myOtherFile.m
edit myOtherFile.m

Thus four files are opened in the Octave GUI editor (as your patch disables checks as expected).

The full output is attached: file #47670

Kai Torben Ohlhus <siko1056>
Project MemberIn charge of this item.
Sun 13 Oct 2019 08:14:09 PM UTC, comment #15: 

Kai, thank you for testing. Please find enclosed a patch where the test for opening an already opened file is (partly) disabled. Moreover, there are some debug outputs  printed in the console window while a file is opened. Could you please post them after having tested with the patch?

(file #47662)

Torsten Lilge <ttl>
Project Member
Wed 09 Oct 2019 11:16:32 AM UTC, comment #14: 

Also, the file in the editor (file residing on the Google Stream G: drive) usually closes when I run it using F5.

Perhaps this is a clue.

Matt Wheeler <mgw66>
Wed 09 Oct 2019 03:42:36 AM UTC, comment #13: 

Torsten, I am able to test your patch.  At my work we also "use" GSuite, but I do not use GDrive under Linux.  I managed to reproduce the issue on a separate Windows machine, pretty weird and annoying, I agree.

Can you make your patch available for the stable branch?  From Octave stable I sometimes build the MXE installer for testing on that separate Windows machine.

But please be patient with the result.

Kai Torben Ohlhus <siko1056>
Project MemberIn charge of this item.
Tue 08 Oct 2019 08:45:00 PM UTC, comment #12: 

I just had another look into the sources and the cause might be the test whether the file, that should be opened as second file, is already open or not. If this test really causes the issue, then same_file () returns true in this specific case or the file name strings passed from the open file dialogs are identical.

Is anyone with access to Google Drive Stream building octave for windows from the sources? If so, I could provide a patch for testing.

Torsten Lilge <ttl>
Project Member
Tue 08 Oct 2019 01:46:57 PM UTC, comment #11: 

Same problem. Can't open a second file when one is open from Google Drive File Stream (G:\My Drive). This is a painful limitation.

I tried using a Windows 10 hard link to refer to the folder using a name without spaces. This did not solve the issue. Still can't open a second file in the Octave editor.

Matt Wheeler <mgw66>
Sun 03 Mar 2019 09:25:59 PM UTC, comment #10: 

Unfortunately the problem raises in the new version 5.1.0 either.

Christos Sevastiadis <csevast>
Sat 02 Mar 2019 09:04:52 PM UTC, comment #9: 

Version 4.4.1 is deprecated and no longer supported.  Please try with the latest stable release which is 5.1.0.  The problem is likely to have been fixed.

Rik <rik5>
Project Administrator
Sat 08 Dec 2018 11:21:02 PM UTC, comment #8: 

The Google Drive File Stream is part of the G Suite, which is for Business and Education accounts. I'm using it through my educational account. Thus, I have to be precise to help you.


  • The selection dialog does appear but the selected file does not open.
  • After creating as many new tabs as I want, the second file still can not be opened.
  • Yes, it is possible.

After experimenting with the idea of the new empty tabs of the second bullet I found out that the files are opened but they are not showing. I opened some empty tabs. I saved one of them with a name, let say "test1.m". When I try to save another one with the same name, after the positive answer to the question dialog about replacing the existing one file, an error dialog opens informing that "File not saved! A file with the selected name <directory path>/test1.m is already open in the editor", where the <directory path> is let say "G:/My Drive/TestDirectory".

I hope that the last description will help you.

Christos Sevastiadis <csevast>
Sat 08 Dec 2018 07:46:20 AM UTC, comment #7: 

I wanted to test it but unfortunately Google Drive Stream is only available for Google Business Accounts (or am I missing something?). In order to figure out what might be going on, I have a few questions:

  • What exactly happens when you try to open the second file via the "Open" menu entry? Does the file selection dialog appear but the selected file does not open or does nothing happen at all?
  • When having the first file opened, what happens when you create a new tab (menu "File" > "New Script" or "Ctrl-N") and then try to open a second file?
  • Related to above: What happens if you close the empty editor tab after octave's startup and then try to open the first file? Is it possible?
Torsten Lilge <ttl>
Project Member
Fri 07 Dec 2018 04:14:05 PM UTC, comment #6: 

I don't think that the issue should be closed. I described a way to come over the problem but it is not its solution. Octave GUI has problem to open script files in its Text Editor when the files are stored in a Google File Stream virtual drive, which it has by default a base root "G:\My Drive". I am using a lot of IDEs, based on QScintilla or not, in Python or in Java, in different computers with Windows 10 and Windows 7. None of them has the same behaviour as Octave. I hope that now the problem can be reproduced and somebody from the development team will fix it.

Thank you very much for your interest.

Christos Sevastiadis <csevast>
Fri 07 Dec 2018 12:29:51 PM UTC, comment #5: 

OK, thanks for reporting back.

Before closing this bug report, I think it is of interest to know WHY Google File Stream behaves that way with Octave. After all, working in the cloud is part the future for many an Octave user, so IMO this should work.
Could it be that Google File Stream allows a connection to just one file at a time, or something along that line?

Philip Nienhuis <philipnienhuis>
Project Member
Thu 06 Dec 2018 07:00:14 PM UTC, comment #4: 

Alright, I found out when it happens. It has nothing to do with the Octave version because I upgraded it already and its behaviour is the same. I tried with a white space including path in a common drive (D:) for the Current Directory and the Octave behaviour was right, like yours. Thus the problem raises in the special case of Google File Stream virtual drive and maybe not because of its white space including base path "G:\My Drive". As I see, to come over the problem I have to copy my scripts to another drive to work with them in the Text Editor.

Christos Sevastiadis <csevast>
Thu 06 Dec 2018 06:22:34 PM UTC, comment #3: 

Thanks, that explnation helps.

I tried with Octave-4.4.1 (current release) and 5.0.0 (dev version) and I cannot reproduce this bug with .m files in e.g.,
"C:\Users\philip\MyDocs\My eBooks"

Please upgrade to 4.4.1, try again and report back.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 05 Dec 2018 08:45:24 PM UTC, comment #2: 

I don't know if it is a bug or not but when the path of the Current Directory includes whites paces then the problem raises. I open one file in the Text Editor and then I try to open another one from the same Current Directory and it doesn't open. A solution to come over is to use only white space free paths, but the Google File Stream is using by default the "G:\My Drive" as base path.

Christos Sevastiadis <csevast>
Wed 05 Dec 2018 08:01:46 PM UTC, comment #1: 

Just FTR, I can't reproduce this on my Win10 and Win7 boxes with
the development version of Octave.

But maybe I do not fully understand your case. Do you want to open the very same file twice in the editor

Philip Nienhuis <philipnienhuis>
Project Member
Tue 04 Dec 2018 10:50:17 AM UTC, original submission:  

Since the version 4.4 (now updated to version 4.4.1) I can open only one file in the Text Editor. With one file already opened I cannot open any other one, either by double clicking on the filename in the File Browser, nor applying the "Open an existing file in editor" action button. I have to close the already opened file and open another one. The Text Editor doesn't accept more than one file to be opened.

My installation is by the book the octave-4.4.1-w64-installer.exe file, on Microsoft Windows 10 Pro Build 17134.

Christos Sevastiadis <csevast>


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

Attach Files:

Attached Files
file #47672:  main_works.cc added by siko1056 (2KiB - text/x-c++src)
file #47671:  main.cc added by siko1056 (2KiB - text/x-c++src)
file #47662:  bug55161_test_01.patch added by ttl (3KiB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by siko1056 (Updated the item)
  • -email is unavailable- added by mgw66 (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by csevast (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 22 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-01-04 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2019-10-28 siko1056 StatusIn Progress => Ready For Test
    2019-10-26 siko1056 Item GroupNone => Feature Request
        StatusNeed Info => In Progress
        Assigned toNone => siko1056
    2019-10-15 rik5 Carbon-CopyRemoved 72865 => -
    2019-10-15 siko1056 Attached File- => Added main_works.cc, #47672
    2019-10-15 ttl Item GroupIncorrect Result => None
        StatusIn Progress => Need Info
        Assigned tosiko1056 => None
    2019-10-15 siko1056 Item GroupNone => Incorrect Result
        StatusNeed Info => In Progress
        Assigned toNone => siko1056
    2019-10-15 siko1056 Attached File- => Added main.cc, #47671
    2019-10-15 siko1056 StatusConfirmed => Need Info
    2019-10-15 siko1056 Attached File- => Added output-siko1056-2019-10-15_1.txt, #47670
    2019-10-13 ttl Attached File- => Added bug55161_test_01.patch, #47662
    2019-10-08 siko1056 StatusNeed Info => Confirmed
        Release4.4.0 => 5.1.0
    2018-12-18 mtmiller SummaryCannot open multiple files in the Text Editor => Cannot open multiple files from Google Drive File Stream in the editor
    2018-12-05 philipnienhuis StatusNone => Need Info

    Back to the top

    Powered by Savane 3.7