When I download files, the permissions are set to 600. My umask is set to 27, so others in my group can read new files. Mozilla ignores this, and I'm unable to find a config option to make it respect umask.
that's true. it doesn't respect umask at all.
This is worksforme (20020421 Linux). Did you set the umask and then launch mozilla from that shell? Reporter (adam shostack), please can you clearly state what steps you took to produce this bug (e.g. what was downloaded where to and how you checked) and follow the guidelines at http://www.mozilla.org/quality/bug-writing-guidelines.html Could you also check to see whether this bug is still present in a recent build (Moz1-RC1 or a new nightly build). If this bug does not occur please can you resolve it worksforme.
It turns out that umask was getting inherited from something in gnome that was setting it which I've yet to track down. Mozilla launched from the command line works as expected. I've resolved to worksforme, per your request.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
Reopening since I'm using trunk 2002050821 build under KDE 2.2.2 and Mozilla definitely ignores my umask. But it happens only when saving downloaded files to disk (and only then, saving web pages etc. honours my umask). In addition, a file has to be downloaded by left-clicking on a link to it, then choosing "Save this file to disk". If I right-click and choose "Save Link Target As...", then umask is honoured. My steps to reproduce this: 1. Launching an xterm window 2. Check your umask (mine is 002) 3. From the xterm window launch Mozilla (e.g. type /usr/local/mozilla/mozilla) 4. Open a page with a file to download (e.g. http://olo.office.altkom.com.pl/domowa/mozilla/download_umask/) 5. Click on the link to that file, select "Save this file to disk...", save in a directory on your disk 6. Check file's permissions. In my case, it's 600 despite the fact that my umask is 002. 7. Delete that file 8. Right-click on tha link and select "Save Link Target As...", save in the same directory 9. Check file's permissions. I had 660 (so this time it's in accordance with umask).
Status: VERIFIED → UNCONFIRMED
Resolution: WORKSFORME → ---
Hmm, well I don't claim to be a umask pro but I don't think the problem is with umask but rather with the mode... The umask is used to turn *off* certain bits so if a file was creatd with the mode 600 then a umask of 002 is going to produce a file with the permissions 600... However as Aleksander has pointed out that using the right mouse button save target link as produces a file with the correct permissions to left clicked saved file so I assume that two different modes are being used when it would make more sense to use 666 in both cases (this would produce the reporter's expected behaviour). Confirming (20020426 Linux). If you are trying to reproduce this then don't forget to delete the file between saves.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ben, I'm cc-ing you because this might be your component. firstname.lastname@example.org wrote: > Hmm, well I don't claim to be a umask pro but I don't think the problem is with > umask but rather with the mode... That's my point. When an application creates a file with mode set explicitly to 600 (instead of 666), it indicates that programmer ignores the existence of umask facility on Unix systems. That practice is clearly wrong in my opinion, because it's like trying to access video hardware directly instead of dependinng on system libraries/gui toolkit when creating a simple gui app. It's the do-it-all-yourself thinking that usually spawns from experience in Assembler programming on MS-DOS :-). My message to those programming on Unix/Linux: Don't be afraid to rely on umask. It's always set properly to at least 002 (or 022), unless a user reconfigured the system. I've never seen a UNIX-like system where umask would default to 000. See the discussion in this bug: http://bugzilla.mozilla.org/show_bug.cgi?id=115154#c7
*** Bug 150586 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 124307 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.