[I hope it is appropriate to post this here. I posted on gimp-user and got no feedback on this. I did not want to post as a bug on bugzilla yet in case I am missing something simple.]

Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux.

TIFF ONLY ---- This problem seems *only* to be happening when creating/saving TIFF (.tif) files. If the filetype is something else, then the problem is not happening.

On two different workstations, being run by two different login users, creating files in various different directories, Gimp is creating the files with permissions that are incorrectly too restrictive:

Gimp is making as 644:

-rw-r--r-- 1 jay jsa 1919194 2009-03-31 12:10 tmp.tif

When it should be making as 664:

-rw-rw-r-- 1 jay jsa 1919194 2009-03-31 12:10 tmp.tif

ONLY Gimp is doing this.

Creating files in the exact same manner and saving them to test.png or test.jpg results in _correct_ permissions. It only is a problem with .tif files (so far in my testing).

a) The directories that the files are being created in have perms of 6775:

drwsrwsr-x 3 jay jsa 4096 2007-05-28 15:57 testdir

Files created in a directory with those perms are _supposed_ to be created as 664 which is rw-rw-r--.

b) When any other program, such as vi or touch, makes a file in the very same directory, it is making the perms correctly.

c) I have double checked the user's umask which is correctly 0002 which would result in file creation as 664.

d) We have never had this problem with any other program (when the directory perms are correct, which they are in this case).

e) An associate on a completely different, but virtually identically configured Ubuntu linux system (all same versions). has been able to replicate the exact same problem.

???

1) Is this a (known?) bug?

2) Is this configurable somewhere in Gimp? I can't find it if it is.

3) Is this configurable somehow in the .gimp* rc files and/or from the command line?

Jay

Sorry to bump this, but after 8 days on this list and on gimp-user, there has been absolutely no comment.

Can anybody confirm or deny that this is also happening on their linux systems? Or is it _just_ me?

Should I file a bug report on this? I don't want to clutter up bugzilla if I am missing something silly.

Thanks.

Jay

On 04/02/2009 11:58 AM, Jay Smith wrote:

[I hope it is appropriate to post this here. I posted on gimp-user and got no feedback on this. I did not want to post as a bug on bugzilla yet in case I am missing something simple.]

Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux.

TIFF ONLY ---- This problem seems *only* to be happening when creating/saving TIFF (.tif) files. If the filetype is something else, then the problem is not happening.

On two different workstations, being run by two different login users, creating files in various different directories, Gimp is creating the files with permissions that are incorrectly too restrictive:

Gimp is making as 644:

-rw-r--r-- 1 jay jsa 1919194 2009-03-31 12:10 tmp.tif

When it should be making as 664:

-rw-rw-r-- 1 jay jsa 1919194 2009-03-31 12:10 tmp.tif

ONLY Gimp is doing this.

Creating files in the exact same manner and saving them to test.png or test.jpg results in _correct_ permissions. It only is a problem with .tif files (so far in my testing).

a) The directories that the files are being created in have perms of 6775:

drwsrwsr-x 3 jay jsa 4096 2007-05-28 15:57 testdir

Files created in a directory with those perms are _supposed_ to be created as 664 which is rw-rw-r--.

b) When any other program, such as vi or touch, makes a file in the very same directory, it is making the perms correctly.

c) I have double checked the user's umask which is correctly 0002 which would result in file creation as 664.

d) We have never had this problem with any other program (when the directory perms are correct, which they are in this case).

e) An associate on a completely different, but virtually identically configured Ubuntu linux system (all same versions). has been able to replicate the exact same problem.

???

1) Is this a (known?) bug?

2) Is this configurable somewhere in Gimp? I can't find it if it is.

3) Is this configurable somehow in the .gimp* rc files and/or from the command line?

Jay

Martin,

Sorry, if I was not clear.

You said "Don't top-post please."

My question "Please advise me what I am to do in such situations? What is the correct method? I wish to follow the rules." was asking what am I supposed to do if I am not supposed to bump (is that the same as top-post?) but there has been no reply or interest in the subject, yet the subject (as you thankfully proved) is worthy of attention? Sorry for being unfamiliar with the rule on this.

I have posted the bug.

Thanks for taking the time to confirm that there was an actual problem.

Jay

On 04/10/2009 12:22 PM, Martin Nordholts wrote:

The correct method for what? Filing bug reports? Take a look at http://www.gimp.org/bugs/

And I would prefer to keep the discussion on-list

- Martin

Jay Smith wrote:

Thank you for your reply and information.

Again, I apologize for bumping the topic. Please advise me what I am to do in such situations? What is the correct method? I wish to follow the rules.

Jay

On 04/10/2009 11:36 AM, Martin Nordholts wrote:

Jay Smith wrote:

Sorry to bump this, but after 8 days on this list and on gimp-user, there has been absolutely no comment.

Hi!

Don't top-post please.

This happens to me as well and from looking at the code it also happens for gbr, gih, pat, pnm and raw which opens a file for writing like this:

fd = g_open (filename, O_CREAT | O_TRUNC | O_WRONLY | _O_BINARY, 0644);

E.g png instead uses

fp = g_fopen (filename, "wb");

This inconsistency doesn't make any sense, feel free to open a bug report. The latter is identical to the former apart from the permissions, so we probably want to use the latter for all plug-ins.

- Martin