Fix #2279: File permissions are kept upon save

[tobiasdiez]

Fixes #2279.
JabRef does not directly writes to the bib-file upon save but creates a temporary file which is then copied over the original one. In this process the original file permissions get lost. Should be fixed with this PR (I have not tried it...).
I pushed the code to the branch https://github.com/JabRef/jabref/tree/filePermissions but for some reason the setup files do not show up on builds.jabref.org

• Change in CHANGELOG.md described
• Tests created for changes
• Screenshots added (for bigger UI changes)
• Manually tested changed features in running JabRef
• Check documentation status (Issue created for outdated help page at help.jabref.org?)
• If you changed the localization: Did you run gradle localizationUpdate?

[lenhard]

Good job! Give it some time. If there is no build tomorrow, try restarting. Then @g-mos should give it a try and see if it keeps permissions.

[g-mos]

I would be happy to test whatever is needed. Since I am new to this, inform me and tell me, when and what I need to download.

[koppor]

@tobiasdiez Could you create a branch at the JabRef main repo?

[tobiasdiez]

@koppor I pushed to a branch in the main rep (https://github.com/JabRef/jabref/tree/filePermissions) but no build appears under http://builds.jabref.org/.

[matthiasgeiger]

A test failed at circleCI... I've restarted the build: https://circleci.com/gh/JabRef/jabref/8328

[tobiasdiez]

Thanks @matthiasgeiger, it worked!

@g-mos could you please install the development version from http://builds.jabref.org/filePermissions/ and test if the permission issue is indeed resolved. Thank you!

[stefan-kolb]

LGTM 👍
Just for clarification: why don't we write directly to the bib file? Would be cleaner?!

[g-mos]

I can confirm that the permissions of the files are kept. Therefore the issue at hand is fixed.
BUT! Due to the logic as @tobiasdiez described every time a different user saves the file user/group owners of the file change. For common usage this is not important, even for my scenarios this is not important. I presume that you need the "opening new file philosophy" for triggering when actual changes happen in a group/collaboration environment. But to add to @stefan-kolb idea, instead of creating a new file can you clone at the beginning and open the clone? Then save to the original? Just as an idea?
Either way thanks @tobiasdiez for the quick fix!
The above was checked in two computers (Ubuntu 15.10/16.04)

[Siedlerchr]

Why "are"?
Functionality is singular
Either you let the is or you use functionalities

[tobiasdiez]

the object is "categories" which is plural.

[Siedlerchr]

LGTM for the moment I think we can merge it in.
We should think about/creating a new PR for checking if the copy is really necessary

[tobiasdiez]

@g-mos Thanks for your feedback (and reporting the issue in the first place).
I will now merge this PR, so the fix will be included in the next version.
I don't think we will completely change how files are saved in the near future. I think the reason for writing everything to a new file is that it provides an additional layer of security. If something gets messed up during the writing process, the original file is untouched and without damage.

[g-mos]

@tobiasdiez I agree for the security layer. My idea is
a. copy the file, so that permissions, owners stay the same
b. open the copy
c. if the user saves --> save to the original file.
I do not know if this is feasible....

[Siedlerchr]

@g-mos Due to a problem on windows I slightly had to change the code. Follow up is in #2286
I would like you to test the build from here:
http://builds.jabref.org/copyPermissions/

[g-mos]

Unfortunately @Siedlerchr, this new version returns to the original problem. The permissions are completely destroyed. rw for user and no access to everybody else. It is also changing of user/group ownership to the user that shaved the jabref file. Sorry for the bad news.
To add if it might help. The .bak file has the proper permissions and the proper ownership.

[Siedlerchr]

@g-mos Okay, thanks for the feedback. I will investigate this further. In the meantime you can revert back to the version before.