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

[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]

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)?

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.

[thomas]

Looking at the wxTempFile sources, you see that it is unsafe, anyway. Typical...

Calling Commit() actually deletes a possibly existing file and then tries to rename the tempfile to the deleted file's name (which may work or not, and which may be prevented by encountering a crash or an exception).
Thus, if things go wrong for some reason, you may end up with your data not saved (the temporary file is deleted in the destructor) and the existing file deleted from disk...

Actually, it should rename the existing file, then rename the new file, and only if that was successful, delete the original (preferrably after syncing). Then at least you would keep the original file in the worst case (renamed, but nevertheless existing).

[thomas]

There goes, I implemented saving documents to a temp file, not touching any file attributes, with proper renaming in the correct order, and deletion of temp files after a grace period.

Using a grace period is not ideal, but it is as good as we can do, and surely better than deleting the original file before being sure that the new file is good.
As we don't know anything about the underlying filesystem (it might even be on another physical machine), there is not much we can do to ensure all data is really synced.

This function will have to be tested for a week or two before it goes public, though.

[Blue-Tiger]

woohooo really nice to hear this

[sika]

Hi !
I'm using one of the last nightly and i've got the same little problem (the messagebox saying : "Failed to set temporary file permissions (error 1: Operation not permitted)").
Do you plan to fix it or not ?
thanks 

[sika]

this messagebox is a bit annoying... no plan to include the function described by thomas ? :?

[thomas]

The function was included months ago (FileManager::Save). It's just not being used everywhere.

[sika]

ok thanks !
and do you plan to use it everywhere in the near future ?

[sika]

bump

[sika]

ok, my problem is solved !
in fact, the problem was that in my /etc/fstab, the partition was marked as owned by root... so i've just made it mine (gid and uid) and it works perfectly now without any "Failed to set temporary file permissions" error !!