#776 File permissions changed when saved on Windows

[Walt]

Saving files using CodeBlocks on Windows 7 results in the file permissions being changed. This is bad for the workflow where one uses CodeBlocks to edit the project but cygwin for other elements, including git.

Example workflow:

Within cygwin terminal:

• Checkout project from git reproistory
  Within Code:Blocks:
• Make change to file
• Save file
• Undo change to file
• Save file
  Within cygwin terminal:
• git diff

Expected behaviour: No changes
Acutal Behaviour: File permissions changed

Before saving in CodeBlocks a file has Windows (NTFS) permissions: User = Read|Write|Special.
After saving in CodeBlocks a file has Windows (NTFS) permissions: User = Full|Modify|Read&Execute|Read|Write.
Other permissions also change, e.g. Everyone group changes.

This may be related to Windows policies but other applications, e.g. Notepad++ do not change file permissions when saving a file on the same platform (same user, same login session, same machine).

[bluehazzard]

This is probably because codeblocks goes a two file save approach:
1) Create temp file and save the content
2) Delete original file
3) Rename temp file to original filename

So the new temp file has probably other permissions then the original on windows...
The question is why you can save a unmodified file....

[edit:] probably the undo thing does not uncheck the "isModified" flag of the file

[Walt]

The issue is not about being able to save files. I change the file and save it then the permission changes. I may subsequently undo the change and resave resulting in a file that does not need to be committed to version control or may commit the changes I have made but either way the file permissions are erroneously changed.

Why does CodeBlocks perform a two stage save? I don't think I have experienced corruption during save since the 1990s and no other applications I use have this issue.

[Teodor Petrov]

Because it is more transactional I think and less risky. It was done long before I'm in the project, but I'm sure it is useful.
Any way starting with rev #11539 there is an option to disable this mode of operation.

I'll see if I can change the code to preserve the permissions, but I doubt it is possible to preserve the cygwin permissions using win32 api calls...

[Walt]

I look forward to seeing the option in a nightly build soon... Other applications manage to avoid changing file permissions so it is probably around the permissions assigned when creating a new file. There may be a win32 api method to obtain the permissions of the current file or even just copy the current file - though it may be worth reconsidering why the double save method is in place, i.e. does it continue to provide benefit and if so, which option is most beneficial (e.g. should one be default)?

[Teodor Petrov]

For sure there is a way to obtain permissions for a file, but I doubt there is a way to get the cygwin permissions. As far as I know cygwin tries to mimic unix's permission and the file permissions on windows are totally different. For example there is no such thing as executable permission on windows. A file is executable if it has extension .exe, .com or .bat...

This is why I've said that I doubt this would solve your problem. You have to use the option to disable the save-to-temp-and-move.

I don't think we're going to change the default of the option any time soon.