don't edit source

[Ale_88]

Hi i'm a new italian developer with linux and codeblocks. I have install codeblocks and open a cpp file. But i can't  modify the source.. if I press any key on the keyboard in the source nothing is modify.,. why? Thanks

[Jenna]

That happens, if you don't have write access to the file.

[Ale_88]

Ok i have do that chmod 777 main.cpp or chmod 666 main.cpp.. and now i can edit but don't save... help me and sorry for my stupid question...

[Jenna]

You also need write access to the directory your files are in, to be able to save them.

[olipfei]

@Ale_88:

if I press any key on the keyboard in the source nothing is modify.,. why?

Could you go a little bit more into detail here, please? You mean, the source is not modified in the CB editor, or, after trying to save, on the disk? When you try to save, is there any CB dialog shown? Do there remain files with ending .cbTemp alongside your original files? Finally, most interesting to me: do the files you are editing reside on a vfat (FAT, FAT32, ...) file system?

Sorry to have to interfere on this thread, but I also experience problems on LInux saving files from CB, when they are located on a vfat file system (not reiserfs, which is the only other 'real' Linux fs I have to test).

My symptom is that when I try to save a modified file, e.g. mainframe.cpp, then the 'Error saving file' dialog pops up twice (curiously enough!), and a file mainframe.cpp.cbTemp remains on the disk. However, I want to strongly emphasize that I AM able to save the same files from other familiar Linux editors (kate, gedit, vim) on the same file system with the same mount options.

Speaking of mount options, I've also experimented with my settings a little bit. Usually I mount my vfat partition (FAT32 formatted) with umask=0002, uid=root and gid=users, the group I am in as ordinary user, so saving from CB SHOULD work (as it does from other editors!). Nothing changes when using umask=0000, but, setting uid=oliver guess what, saving files from within CB works (nanonanet, as we say in some German slangs...).

@jens:

That happens, if you don't have write access to the file.
...
You also need write access to the directory your files are in, to be able to save them.

As you can guess now, I believe this doesn't seem to be the only source of the problem, at least not in my case. You could argue that I have a workaround using the aforementioned mount options, but yet, there seems to persist some problem in CB with saving files in the described manner. What I can see from CB's sources I know there have been problems of similar kind which were presumed to be fixed (r5104, in particular filemanager.cpp, is this right?), I'm also aware of http://biplab.in/2008/06/file-permission-bug-of-cb/.

I must admit I don't understand enough of the background facts which can cause such weird situations, but I really would like to help tracking down this bug to finally get rid of it!-)

Regards,
Oliver

[Jenna]

@olipfei:

I will have a look.

I use ext3 as linux fs, but I don't have problems with vfat partitions either,  if I remeber right (I have aproject on a vfat, but mount a subdir of it with bind option).

[Jenna]

@olipfei:

It's not really a C::B problem.

We use the wxCopyFile-function to make a copy of the file, because it respects the file permissions.
wxWidgets does that by a call to the chmod-function.

And that's the problem.

On a vfat-partition you can not have really file-permissions or ownership, so they are set statically at mount-time.
They cannot be changed, even root can't do that.
If you are not the owner of the file and try to change it's permissions you get an error, but on the vfat in your case the owner is always root.
For all other users the wxCopyFile will therefore return an error, and lead our Save()-function to return an error, too.

There is no easy (cross-platform) way to work around this.

A possible solution would be to tell the user that a backup-file might not exist and ask, if he wants to try to write the file anyway.
But that is a dangerous thing, because there could be a real cause that leads to this error (either a hdd-error or the disk might be full) and so the user might lose data.

So I think the best and cleanest solution would be to set the ownership correctly.

By the way:
Even the owner of a file can not really change the permission on a vfat-partition, but he does not get an error if he tries it.
So in this case the wxCopyFile-function works.

[olipfei]

Hmmmmmm...

After I posted the above message it came to my mind that so far I completely ignored the second player in the whole match: wxWidgets. So I did some further tests with the programs I wrote using the wx library, and with the same setting as for CB they also produced an error (which I don't recall at the moment, working on Windows right now) when saving data to the vfat partition. However, I do not use wxCopyFile anywhere in my code, the function concerned is wxTextFile::Write(). Any idea if there could be a common ground? Should I submit a bug report to the wx tracker?

Btw thanks for the explanation and sorry for erroneously suspecting CB!-)

Regards,
Oliver

[Jenna]

Btw thanks for the explanation and sorry for erroneously suspecting CB!-)

No problems.

If I interprete the message sent by wxTextFile::Write (in debug-mode) correctly, it tries to create a temporaryfile.

The wxTempFile constructor calls it's own Open()-function and there it tries to set file permissions via systems chmod-call.
This call fails for the same reasons as in wxCopyFile.

So it's a problem of wxWidgets, that should ignore that it's impossible to set the file permissions if we are on a mounted vfat (or similar).