User forums > Help

[Linux] Problems when saving files on a FAT-Partition

(1/3) > >>

Blue-Tiger:
Hi there!
I'm using the latest nightly (the one from the 25. may) under Linux (Ubuntu 6.06). Whenever I want to save a file I get a messagebox that reads "Failed to set temporary file permissions (error 1: Operation not permitted)", altough the files get saved.

The project Im working on lies on a FAT32-partition. If I copy all the files over to a ReiserFS-partition everything works fine.
So it seems that whenever CB tries to save a file it also tries to set some file permissions. Of course on FAT-partitions there is no such thing as filepermissions, hence the error-message (at least that's what I guess, but you're the devs ;) ). So: can I somehow tell CB not to do this? Even though I can live with it, it is kind of annoying. Simply continuing the development on the ReiserFS-partition is not an option, as I need to access the files from both windows and linux.

thomas:
There is no way to prevent Code::Blocks from doing that, since it is done by wxWidgets implicitely if you use wxTempFile (and on a "normal" filesystem it would work, too).

If that helps, you can suppress the error message (and all other error messages related to saving!) by adding the line:

wxLogNull null_logger;

in sdk/globals.cpp, at line 433.

Please do not ask for this being added to the code base, though. It will not be.

Be aware that you will not get any error messages if saving a file fails entirely (for whatever reason) with this modification. It may, however, still be a viable option in your specific case.

Yet another alternative might be to replace the wxTempFile with a normal wxFile. This requires a few other lines to be changed too, and will prevent your specific error from happening, but will still report other failures.
This solution is unsafe and may result in loss of data, for example in case of a power loss or an application crash while saving. We use wxTempFile for that reason.

Blue-Tiger:
Thanks for the explanation. Unfortunately none of your suggestions is a long-term solution of this issue. Working on a FAT-partition under Linux isn't such uncommon IMHO, especially for crossplatform-tools. So I guess sooner or later there will be other ppl having this problem. Well, I'll try to contact the wx-Ppl about this, maybe there is something they can do about it.

thomas:
Hmm... I wonder whether it may be worth implementing a proprietary class like wxTempFile, should not be so awfully hard to do.

Basically, all we need is writing to a temporary file, and swapping filenames once this is done. Should not be impossible to implement :)
I wonder about syncing to disk, though. Don't know if wxTempFile does that, and unsure whether it is strictly necessary, too (journalling should do the job on every decent fs).

If we don't tamper with access flags at all, then the umask of the currently active user should automatically be used on file systems that support it, so actually this should always work (or so I hope)?

Blue-Tiger:

--- Quote from: thomas on May 26, 2006, 10:31:29 pm ---Hmm... I wonder whether it may be worth implementing a proprietary class like wxTempFile, should not be so awfully hard to do.

Basically, all we need is writing to a temporary file, and swapping filenames once this is done. Should not be impossible to implement :)
I wonder about syncing to disk, though. Don't know if wxTempFile does that, and unsure whether it is strictly necessary, too (journalling should do the job on every decent fs).

If we don't tamper with access flags at all, then the umask of the currently active user should automatically be used on file systems that support it, so actually this should always work (or so I hope)?

--- End quote ---

Well, if you only want to do this because of this Linux/FAT - issue, you can just take the normal wxTempFile and rip out the file-permission part.

Navigation

[0] Message Index

[#] Next page