Bug Report: [#18755] C::B hangs for 20 seconds while opening large project...

[MortenMacFly]

Now let's test it (especially on win with files spread over two and more volumes)

I can do it later on. What needs to be tested:
- project / project layout file saving / loading with files on same and different volumes
- project / project layout file saving / loading with files on UNC path's
- especially saving project files below and above a certain source folder
- compilation process and UI behaviour where this path's are used

...anything else?

[dmoore]

Now let's test it (especially on win with files spread over two and more volumes)

I can do it later on. What needs to be tested:
- project / project layout file saving / loading with files on same and different volumes
- project / project layout file saving / loading with files on UNC path's
- especially saving project files below and above a certain source folder
- compilation process and UI behaviour where this path's are used

...anything else?

I haven't tested everything, but I made up a one file ConsoleProject, added another file on another volume to a new target then compiled and ran that target successfully.

Code

-------------- Build: ExternalFileProject in ConsoleProject (compiler: GNU GCC Compiler)---------------

mingw32-g++.exe -Wall -fexceptions  -O2     -c t:\CProjects\ConsoleProject\main.cpp -o obj\Release\t\CProjects\ConsoleProject\main.o
mingw32-g++.exe  -o bin\Release\ConsoleProject.exe obj\Release\t\CProjects\ConsoleProject\main.o   -s  
Output size is 478.50 KB
Process terminated with status 0 (0 minutes, 2 seconds)
0 errors, 0 warnings (0 minutes, 2 seconds)

Also did the same for adding a file just one directory above the project and no problems there either.

No problems loading/saving the project. The project tree shows the file on a separate volume nested appropriately under Sources/t/CProjects/ConsoleProject/main.cpp, and the different project tree options work as expected. For the file one directory above, the basedir of the tree adjusts appropriately.

So far so good.

[MortenMacFly]

Finally: Some time for testing - but unfortunately this patch breaks handling of file names on UNC drives.
If you add a file on an UNC drive this is immediately broken and cannot be opened.

While the relative file name in the file's properties look correct (it remains the UNC path w/o simplification), the absolute path is wrong: It is compiles ad project base path plus the UNC path, like:
C:\Folder\Base\SERVER\folder\file.cpp

This is obviously wrong. :-(

[MortenMacFly]

What also doesn't work:

Have this layout:
[Root][src] - file.cpp
[Root]proj.cbp
- Open project
- Save project under:
[Root][prj] - proj.cpp

-> All files are broken, project file is broken.

[MortenMacFly]

...what also doesn't work:
Have this layout:
[C:\Folder][src] - file.cpp
[C:\Folder]proj.cbp
- Open project
- Save project under:
[D:\Folder] - proj.cpp

-> All files are broken, project file is broken.

I'm afraid all this is clearly a "No-go"...

[dmoore]

What also doesn't work:

Have this layout:
[Root][src] - file.cpp
[Root]proj.cbp
- Open project
- Save project under:
[Root][prj] - proj.cpp

-> All files are broken, project file is broken.

Did this work previously?

[dmoore]

While the relative file name in the file's properties look correct (it remains the UNC path w/o simplification), the absolute path is wrong: It is compiles ad project base path plus the UNC path, like:
C:\Folder\Base\SERVER\folder\file.cpp

So we need to write our own implementation of GetVolume that treats \\Server (or //Server) as a volume?

[MortenMacFly]

So we need to write our own implementation of GetVolume that treats \\Server (or //Server) as a volume?

I'd simply say do never change files with UNC path's. So before checking for the volume we should check for UNC path's and then leave it as it is. This would not require and modification of GetVolume.

[Jenna]

So we need to write our own implementation of GetVolume that treats \\Server (or //Server) as a volume?

I'd simply say do never change files with UNC path's. So before checking for the volume we should check for UNC path's and then leave it as it is. This would not require and modification of GetVolume.

But what if the projectfile (*.cbp) has an UNC path ?

[MortenMacFly]

But what if the projectfile (*.cbp) has an UNC path ?

You mean if the project file itself is on an UNC path? In that case, there is no common top-level path and all files should use absolute file names / path's for all purposes. However, this is a very special case.

If you mean it contains files that are on an UNC path, these files must always be handled without simplifications, so there is no base path for them and also no relative path's. Those file should always only use the full path.

In the project tree they are shown as:
[ROOT]-[SERVER]-[FOLDER]-[...]-File.cpp
...while "normal" files are shown as:
[ROOT=BASE_PATH]-[FOLDER]-[...]-File.cpp

[MortenMacFly]

...btw: having re-applied my original patch, most things work, except UNC handling. (Did I mention that UNC sucks, btw?! )

[Jenna]

...btw: having re-applied my original patch, most things work, except UNC handling. (Did I mention that UNC sucks, btw?! )

But this will lead to the slowdown again.
Checking for an UNC pat should not be too hard.

And for the other issue (if the projectfile itself is aved on a different volume, after calculating the commonTopLevelPath):
does saving the project on a different path trigger the recalculating of the commontopLevelPath (and rebuilding the project tree) ?
If not, the error is there.
I hope I find the time to look into it today.

[Jenna]

Can you test the attached patch ?
It's not tested in any case by me (just a quick hack), so be careful with real projects.

[MortenMacFly]

But this will lead to the slowdown again.

True. But my trial was to see if the changes of dmoore actually caused the mis-behaviour.

does saving the project on a different path trigger the recalculating of the commontopLevelPath (and rebuilding the project tree) ?

Well it works for me now (I'll double-check in a minute) - so my guess is that the error was in the patch...

Can you test the attached patch ?

...will do. But it may take some time again.

[dmoore]

But what if the projectfile (*.cbp) has an UNC path ?

You mean if the project file itself is on an UNC path? In that case, there is no common top-level path and all files should use absolute file names / path's for all purposes. However, this is a very special case.

what about if everything is on the same UNC path (project and project files). Are you suggesting that the files in this project should always be treated as absolute? (I hope not.)