Closed
Bug 325334
Opened 19 years ago
Closed 8 years ago
umask is hard coded to 755 for directories when do save as complete web page
Categories
(Core Graveyard :: Embedding: APIs, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: fuerst, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: helpwanted)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050925 Firefox/1.0.4 (Debian package 1.0.4-2sarge5) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050925 Firefox/1.0.4 (Debian package 1.0.4-2sarge5) Firefox has the umask 755 for the directory containing the images when a user dows save a webpage in complete mode. This gives some serious problems when firefox is used in a network. Othe rpeople can not move arround the images of the saved page because they only have the read access to this folder. I'm not a developer, but for comparison, OpenOffice, which also is an application which runs on several plattforms, uses the umask set in the environment. Example: In Gnome, my umask is set to 002 When I start openoffice, files I save and directories I create in the file dialog have permissions 775 (directories) and 664 (files). When I open a shell and set umask to 022 and start openoffice from this shell, it takes this umask to create files and directories. So files have then 644 and directories 755 as permissions. It would be really really great if firefox also would be able to get the umask from wherever it can take them except hardcoded. Maybe ask the openoffice people how they did that? Thank you very much Reproducible: Always Steps to Reproduce: 1. Save a file, complete 2. 3. Actual Results: the file has 664, the directory with the images 755 as permission Expected Results: depending on the umask settings, in my case file has 664, directory 775
Related to Core bug 253052, Core bug 279084 or maybe Core bug 120679?
(In reply to comment #1) > Related to Core bug 253052, Core bug 279084 or maybe Core bug 120679? > Comment #9 describes exactly my problem, yes. I'm sorry, I did'nt find this bug, so this one is obsolete as far I understood the discussion about the other bug. I'm basically complaining about the hardcoded umask and wish Firefox taking the umask set in the environment. Thank you
(In reply to comment #2) As a work arround I did the the following: I downloaded the source and edited the file /mozilla/embedding/components/webbrowserpersist/src/nsWebBrowserPersist.cpp and changed the line 1611 from rv = localDataPath->Create(nsILocalFile::DIRECTORY_TYPE, 0755); to rv = localDataPath->Create(nsILocalFile::DIRECTORY_TYPE, 0775); and it created the directories with permissions 755 as expected. Of course this is not the solution, because maybe other want 755, so it has to take the value from the umask. regards
Comment 4•18 years ago
|
||
*** This bug has been marked as a duplicate of 279084 ***
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Comment 5•18 years ago
|
||
Philip, the bug you duped this to is expired, and I really don't see how this is fixed. Reopening.
Status: RESOLVED → UNCONFIRMED
Component: General → Embedding: APIs
Product: Firefox → Core
Resolution: DUPLICATE → ---
Version: unspecified → Trunk
Updated•18 years ago
|
QA Contact: general → apis
Comment 6•18 years ago
|
||
If we just want to use the umask, we should use 0777 here (since the umask gets factored into whatever bits are used here). Is that what we want to do?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 7•18 years ago
|
||
I think it is, yeah.
Comment 8•18 years ago
|
||
Ah, except of course on Windows that will probably do the wrong thing. Or will it? I forget exactly how the permissions bits work on Windows. It feels to me like we should sort this out once and for all and have defines (possibly different on different platforms?) for the permissions to use for this sort of stuff.
Comment 9•18 years ago
|
||
(In reply to comment #8) > Ah, except of course on Windows that will probably do the wrong thing. Or will > it? I forget exactly how the permissions bits work on Windows. They don't. They are ignored there.
Comment 10•18 years ago
|
||
But I seem to recall them affecting the world-readable state of files somehow...
Comment 11•18 years ago
|
||
http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/src/md/windows/w95io.c#191 PR_Open ignores the mode argument. PR_OpenFile seems to use it, but we don't call that. (http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileWin.cpp#394. So we don't actually call PR_Open either at the moment...)
Updated•18 years ago
|
Keywords: helpwanted
Comment 12•8 years ago
|
||
Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.
Status: NEW → RESOLVED
Closed: 18 years ago → 8 years ago
Resolution: --- → INCOMPLETE
Updated•5 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•