Unable to read source file

[BlueHazzard]

what does the debugger log tell you? Pleas enable full debugger logging and post it here (Settings->Debigger->select default, ot gdb on the right side->Full logging

[LuiZiffer]

Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target:
src
Adding source dir: /home/luiziffer/trunk/src/
Adding source dir: /home/luiziffer/trunk/src/
Adding file: /home/luiziffer/trunk/src/devel30/codeblocks
Changing directory to: /home/luiziffer/trunk/src/devel30
Set variable: LD_LIBRARY_PATH=.:/home/luiziffer/trunk/src/base/tinyxml:/home/luiziffer/trunk/src/devel30:/usr/lib64:

[debug]Command-line: /usr/bin/gcc -nx -fullname -quiet  -args /home/luiziffer/trunk/src/devel30/codeblocks
[debug]Working dir : /home/luiziffer/trunk/src/devel30

Starting debugger: /usr/bin/gcc -nx -fullname -quiet  -args /home/luiziffer/trunk/src/devel30/codeblocks
Setting SHELL to '/bin/sh'
done

[debug]gcc: error: unrecognized command line option -quiet
[debug]gcc: error: unrecognized command line option -nx
[debug]gcc: error: unrecognized command line option -fullname
[debug]gcc: error: unrecognized command line option -args

Debugger finished with status 1

I found the setting Full (Debug) Log in Common

[oBFusCATed]

Your debugger settings are wrong.
You've set gcc as debugger instead of the correct gdb.

[BlueHazzard]

Your debugger settings are wrong.
You've set gcc as debugger instead of the correct gdb.

You can fix this in Settings->Debugger->Default on the left side->Executable path-> point it to gdb

[tianrenli92]

I figured out the reason.
I created two files. test has 616 bytes, which cannot be opened in c::b in Ubuntu (Windows subsystem), with the error described in the original post, and test2 has 617 bytes, which can be opened:
https://imgur.com/a/3eZv6kG
Notice the size on disk, test is 0 byte, while test2 is 4KB.
This happens if the file is so small that its contents and the filesystem bookkeeping fit in 1KB. To save disk space, NTFS keeps small files "resident", storing their contents right in the file record, so no cluster has to be allocated for it.
reference: https://superuser.com/questions/1030800/how-can-a-files-size-on-disk-be-0-bytes-when-theres-data-in-it

TL;DR: If the file is too small (<617B), it may not be found by c::b.

Anyone know how to report the bug?

[ked]

Hi there!
I encountered exactly the same problem with both installations of c::b 16.01 and 17.12, regardless of wx2.x/wx3.x on a Win 10 subsystem for Linux Ubuntu installation (Bionic ver). It seemed completely random which files c::b displayed or not. All files I've tested are completely equal in terms of encoding, permissions, etc. and fully visible in other editors (vi, emacs, gedit, etc) so the discovery of the file size < 617B issue by tianrenli92 really saved my day, and probably the coming week!!! Thank you!!!
The quick fix is of course just to add a few # signs in the files smaller than 617B, but a bug-fix is probably appreciated 

What is the latest news about this issue? Could not find anything about it elsewhere...

[oBFusCATed]

What is the latest news about this issue? Could not find anything about it elsewhere...

Same as before. Someone has to install a debugger, build debug versions of cb and wx and try to see what is going on.

I have enough platforms, so I cannot bother to debug another one. Sorry.

[ked]

Thanx anyway for discovering the file size relation to the problem. I can live with adding #-es to exceed the critical file size, and debugging c::b source code (and similar) is, however, waaaay out of my knowledge.

[BlueHazzard]

no windows 10 to debug :/

[Miguel Gimenez]

I have Windows 10 (64 Pro and 32 Home) and don't have such problem with a 71 byte long file.

I think it is related to the Windows Subsystem for Linux file system adaption layer, both posters are using it.