After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 795496 - Error renaming temporary file: Permission denied
Error renaming temporary file: Permission denied
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: General
2.10.0-RC2
Other Windows
: Normal major
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2018-04-24 01:03 UTC by Sora Hjort
Modified: 2018-05-24 19:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
--Version --Verbose (1.77 KB, text/plain)
2018-04-24 01:03 UTC, Sora Hjort
Details

Description Sora Hjort 2018-04-24 01:03:27 UTC
Created attachment 371308 [details]
--Version --Verbose

OS: Windows 7 & 10

This bug started in 2.9.8 and exists in 2.10 RC2. But it did not exist in 2.8.22 or prior. So this is new.

This may be related to Google Drive, as I save my work within my sync folder. I have not ran into it in tests outside of the sync folder. It does not matter if Google Drive is paused, or is shut down after running into the issue. 

I have not tested to see if any other sync services are affected.

Steps

Open Existing File in the Google Drive folder

Wait about 5 or 10 minutes (Usually it's immediately after loading, but it can take several minutes sometimes)

Try to save

Run into an error, output is

---
Saving 'G:\Google Drive\ArtStuff\XCF\test.xcf' failed:

Error writing 'G:\Google Drive\ArtStuff\XCF\test.xcf': Error renaming temporary file: Permission denied
---

The only work around is to save as another file, and that will be savable till the next gimp session. Or to have Google Drive be closed (which is not useful due to various stuff)

--Version --Verbose output is an attachment
Comment 1 Sora Hjort 2018-04-25 20:23:24 UTC
Something I forgot to make clear, due to this error it prevents any actual saving. I once lost several hours of work, because I had thought I saved a few minutes prior, made a few non-important changes and closed out. I had click discard changes because of that. Resulting in hours lost. (I normally save within several minutes between saves).

I did try clearing out all the settings, even made sure it couldn't detect gimp 2.8 files to import. A fresh profile. And it still runs into the error.
Comment 2 Michael Schumacher 2018-04-25 21:37:03 UTC
Does Google (or a forum of theirs) have anything about what would be special here?

You're the first to ever report this, to my knowledge.
Comment 3 Sora Hjort 2018-04-25 22:16:28 UTC
(In reply to Michael Schumacher from comment #2)
> Does Google (or a forum of theirs) have anything about what would be special
> here?
> 
> You're the first to ever report this, to my knowledge.

They do not, and trying to get any assistance on it from them does not work from past experiences. It's even questionable they even look at their support forums, since they'll break something in an update and then never fix it.

But as stated this is new to the 2.9 and 2.10 branches. Gimp 2.8 and prior never ran into this issue. And this has been the only program to run into this sort of issue. 

The only other problem I've ran into with Google Drive, unrelated to Gimp (probably), are with programs that are constantly saving files. So using GD for things like Minecraft saves will result in corrupted saves, as well as duplicate chunk files.

As for being the first to report this, I'm honestly not surprised. I wouldn't think many users would be using a sync service for their files. I primarily use it to keep art projects sync'd between my work and home computers, as well as general backup in event of computer failure.

If there are any more in-depth methods to get a better error output of what exactly is going wrong, let me know how. The bug submit guide only mentioned the --version --verbose from what I could tell.
Comment 4 Michael Schumacher 2018-04-26 07:18:29 UTC
Do any other GTK+-based applications have the same issue?

Do you know if Google Drive blocks some of the commom C file access functions?
Comment 5 Sora Hjort 2018-04-26 10:33:59 UTC
The only other GTK related program I have running is Pidgin. But I don't have anything, like it's logs, going through Google Drive.

As for the second question, I don't think so. And I don't see how, since I'm not running GIMP from Google Drive's sync folder. Only things I have in there related to GIMP are my work save folder, as well as secondary folders for custom brushes and patterns. And those last two aren't part of the problem due to the attempt with a fresh profile.

I'm still actively trying to trouble shoot this, and I have two more observations. I suspect the first is unrelated, where as the second potential. I segmented them off with the "--" for clarity. 

--

Something I noticed on the Win7 machine but not on the Win10 machine. For a brief second in the save folder, a file appears ".goutputstream-<six digit alphanumerical number>". This file does not show up when using and older version of Gimp.

If that's the temp file, shouldn't that be created in the specified tmp folder instead of the directory you're saving the file in? If so that could be related to what I said earlier in relation to the Minecraft example.

However I do not suspect this is it since the file is appears and disappears before Google Drive has a chance to realize there was a change.

--

The other observation that maybe a cause, that at the moment that I can think of, will have to wait till later in the day to test. It's currently 2AM and about to head to bed and can't currently test it. What it is though is I noticed earlier that one of my gimp project files had a extra user in the file permission/security settings, with a UID/SID instead of a name. Complete with {} surrounding it.

However that does not show up on my home machine, but the work machine is also turned off. I suspect that it shows up when both machines are online and connected to sync. That or the UID is specific to Google Drive. I'll be comparing the UID in the morning/afternoon if I spot it again.

But if it is the case, and it's related to issue I'm running into with Gimp, it to me could mean either
1. gimp doesn't like the change in permission after loading
2. gimp is not able to handle the odd additional user in the permissions.

The reasons why I suspect this may be related to the issue are: the error itself being related to permissions, and I haven't ran into the issue tonight on my home computer, and as mentioned the work computer is turned off.

Tomorrow I will be testing if the home computer is offline has an affect on the work computer. Among other things.
Comment 6 Sora Hjort 2018-04-27 01:26:15 UTC
Update on that testing. 

The weird account SID that was listed, does not appear to be related. It was not a SID on either computer, and may be from a previous computer the harddrive was in that also had Google Drive. I was able to remove it from the permissions and it has not shown up since, even through restarts. However I still ran into the permission error when trying to save.


The other idea of having the home computer off would make the work computer not run into the error at first looked like it was working for several hours. But it reared back up, and even made it impossible to save a file that was created 10 minutes prior within the same session of gimp.


tl;dr: The SID routes were a bust. There is still something else going on.


I honestly don't what I can test, for better information. I don't even know why I didn't run into any errors last night at home. But considering it took several hours today for me to run into it at work after removing that odd SID from all the files and folders in the sync folder, as well as having the home computer off. It could entirely be luck (unseen factor) that I just didn't run into it.
Comment 7 GNOME Infrastructure Team 2018-05-24 19:32:10 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1370.