User forums > General (but related to Code::Blocks)
Linux file save permission bug
Jenna:
@schickb
yes, my patch is applied to the C::B-version in my repo.
@DrewBoo
you are right, your patch works without problems.
I haven't tested copying the file with wxWidgets, because copying it on commandline with "cp" does not copy the file-permissions, and I believed that wxWidgets uses the same mechanism the OS uses.
That's not the case , but I'm not sure if we can rely on the fact that it works with future releases of wxWidgets or (for example) on Mac.
I cannot test it on other OS's expect on windows. Nevertheless it's the dev's decision if they want to fix this bug and how they do it.
The problem that renaming works, but copying not , is not a real problem I think, because the renamed file should still be there. If not something really went wrong.
DrewBoo:
--- Quote from: jens on April 01, 2008, 12:06:43 am ---I haven't tested copying the file with wxWidgets, because copying it on commandline with "cp" does not copy the file-permissions, and I believed that wxWidgets uses the same mechanism the OS uses.
--- End quote ---
Ha. I didn't know cp wouldn't work. I would have made the same assumption. :shock:
--- Quote from: jens on April 01, 2008, 12:06:43 am ---The problem that renaming works, but copying not , is not a real problem I think, because the renamed file should still be there. If not something really went wrong.
--- End quote ---
Not a realistic problem, agreed. My work experience has tweaked me to always think of ways code could possibly break. :lol: Particularly when digging my hands into other peoples' code.
thomas:
--- Quote from: DrewBoo on March 31, 2008, 11:04:03 pm ---Have you checked if wxCopyFile copies the attributes?
--- End quote ---
If you do that, be aware that you give up some safety. wxCopyFile and wxTempFile are (even though the documentation claims so) not safe.
There is (at least) one situation that I've already encountered too, in which wxWidgets will delete both the old and the new file, making you lose your data. The ultra-paranoid custom file save function that Code::Blocks uses was written as reaction to that.
Ceniza:
What about this simple code to query the file permissions of the original file and assign them to the file-after-safe-saving?
--- Code: ---#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
...
struct stat fileStats;
stat("file.cpp", &fileStats);
// vodoo magic to do safe file saving
chmod("file.cpp", fileStats.st_mode);
--- End code ---
That should do the trick, and it could even work on Mac OS.
Jenna:
Hi Ceniza,
it's simple, but it works.
At least on my Laptop with debian sid (64-bit) with utf-8 as standard-encoding (in C::B and filesystem).
Not tested with other combinations.
On windows the same bug exists and persists.
If I have special rights for some users, they all are set to default (everyone can do everything, all added users get removed) on my w2k-box.
Nevertheless here is your idea as working patch.
Compiles on linux and w2k.
It should not break the "ultra-paranoid custom file save function that Code::Blocks uses".
--- Code: ------ codeblocks-1.0svn.orig/src/sdk/filemanager.cpp 2008-04-02 23:11:44.000000000 +0200
+++ codeblocks-1.0svn.work/src/sdk/filemanager.cpp 2008-04-06 23:22:29.000000000 +0200
@@ -278,6 +278,12 @@
if(!f.IsOpened())
return false;
+ // take file permissions from original file ...
+ struct stat fileStats;
+ stat(name.mb_str(), &fileStats);
+ // ... and give them to the new one
+ chmod(tempName.mb_str(), fileStats.st_mode);
+
if(f.Write(data, len) != len)
{
f.Close();
@@ -313,6 +319,12 @@
if(!f.IsOpened())
return false;
+ // take file permissions from original file ...
+ struct stat fileStats;
+ stat(name.mb_str(), &fileStats);
+ // ... and give them to the new one
+ chmod(tempName.mb_str(), fileStats.st_mode);
+
if(WriteWxStringToFile(f, data, encoding, bom) == false)
{
f.Close();
--- End code ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version