Marking as Fixed and closing report.

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:

https://drive.google.com/open?id=1UMtMC3sOaW8BkeVcDrp3h9MIx9s4oUVd

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.

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

We should consider to push this into the stable branch.

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.

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:

https://stackoverflow.com/a/562830

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)

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

https://www.boost.org/doc/libs/1_71_0/libs/filesystem/doc/reference.html#equivalent

and what will became a function in C++17

https://en.cppreference.com/w/cpp/filesystem/equivalent

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:

https://drive.google.com/open?id=18NYK87hft-SL_gG4neEWEXXWbAj7mIzv

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:

pwd
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

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.

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.

Unfortunately the problem raises in the new version 5.1.0 either.

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.

Answers:

• 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.

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.

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.

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.

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.