Closed
Bug 417037
Opened 16 years ago
Closed 15 years ago
mozStorage chokes on databases over AFP
Categories
(Toolkit :: Storage, defect, P2)
Tracking
()
RESOLVED
FIXED
mozilla1.9.1b2
People
(Reporter: tsteiner, Assigned: sdwilsh)
References
Details
(4 keywords)
Attachments
(2 files)
16.12 KB,
image/png
|
Details | |
1.09 KB,
patch
|
benjamin
:
review+
beltzner
:
approval1.9.0.1+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3 Starting with no ~/Library/Application Support/Firefox directory (where ~ is on an AFP share), I can launch Firefox and type into the address and search bars, but nothing happens when I hit Enter. It is also notable that the browser window is initially very small (just tall enough to see the toolbars), and no default web sites are loaded. The bookmark bar did have a single "Home" link which went to a google search page. From there, I could browse normally via links. By simply making ~/Library/Application Support/Firefox a symbolic link to /tmp/Firefox (a local directory), everything seems to work fine (but the profile is no longer stored on the network). Reproducible: Always Steps to Reproduce: 1. Launch Firefox with a profile on an AFP directory 2. Enter text into the address or search bar 3. Hit Enter Actual Results: Nothing happens at all. Its as if the enter key were never pressed. Expected Results: The requested URL or search page should be loaded. Both the workstation and AFP server are running Mac OS X 10.5
Reporter | ||
Comment 1•16 years ago
|
||
Comment 2•16 years ago
|
||
I can confirm this: Error: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: file:///Applications/Minefield.app/Contents/MacOS/components/nsBrowserGlue.js :: bg__initPlaces :: line 386" data: no] Source File: file:///Applications/Minefield.app/Contents/MacOS/components/nsBrowserGlue.js Line: 386 The error is in initializing Places. I suspect this is due to needing the SQLITE_ENABLE_LOCKING_STYLE SQLite macro uncommented in sqlite.c on OS X. See http://www.mail-archive.com/sqlite-users@sqlite.org/msg21123.html for details. We're seeing this in our mozStorage-backed extension as well, with openDatabase() throwing NS_ERROR_FILE_IS_LOCKED. Latest SQLite command-line client also doesn't work over AFP without that macro. mozStorage seemed to work over AFP in Firefox 2, so this is a regression.
Comment 3•16 years ago
|
||
SQLite changelog lists "Get the SQLITE_ENABLE_LOCKING_STYLE macro working again on MacOSX" for 3.5.7, so I don't know what effect it would have in 3.5.4.2 (which appears to be Fx3's version).
Comment 4•16 years ago
|
||
I can confirm this bug with AFP mounted profile directories. At my place of work our home directories (and therefore firefox profiles) are AFP mounted and Firefox 3 is broken as described by Tim Steiner. This will be a complete show-stopper for us if we upgrade and suddenly everyone's browsers no longer work. As such, I would regard this as absolutely critical to be fixed prior to release.
Updated•16 years ago
|
Component: General → Places
Keywords: regression
QA Contact: general → places
Version: unspecified → 3.0 Branch
Comment 5•16 years ago
|
||
confirming, from the multiple independent confirmations above.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•16 years ago
|
Flags: wanted1.9.0.x?
Flags: blocking1.9.0.1?
Flags: blocking-firefox3?
Assignee | ||
Comment 7•16 years ago
|
||
This may be fixable, but might be a bit slower too - see http://www.mail-archive.com/sqlite-users@sqlite.org/msg34473.html
Comment 8•16 years ago
|
||
Will relnote this, but won't block the release on it. This is something we need to address in a branch update, though.
Flags: blocking-firefox3? → blocking-firefox3-
Keywords: relnote
Comment 9•16 years ago
|
||
I'm having the same show-stopping issue for Firefox 3 RC 2, OS X 10.5.3 It makes me sad - we just went to AFP mounted home directories, and I've lost the FireFox i've been running solidly in beta for months.
Assignee | ||
Updated•16 years ago
|
Assignee: nobody → sdwilsh
Component: Places → Storage
Flags: blocking-firefox3-
Product: Firefox → Toolkit
Version: 3.0 Branch → Trunk
Assignee | ||
Comment 10•16 years ago
|
||
Lovely - the version of sqlite that is in the tree does not compile with the AFP support. We'll need a newer version of sqlite on branch (bug 435414) if we want to try this).
Depends on: 435414
Assignee | ||
Updated•16 years ago
|
Summary: Address and Search bars not accepting input with profile on AFP Home directory → mozStorage chokes on databases over AFP
Assignee | ||
Comment 11•16 years ago
|
||
This enables AFP on the mac. Note, the library on the system that Apple uses also has this enabled. I also cleaned up the Makefile a bit since I was in the area.
Attachment #324848 -
Flags: review?(benjamin)
Updated•16 years ago
|
Attachment #324848 -
Flags: review?(benjamin) → review+
Comment 12•16 years ago
|
||
(relnote added)
Updated•16 years ago
|
QA Contact: places → storage
Assignee | ||
Updated•16 years ago
|
Whiteboard: [has patch][has review][needs bug 435414]
Updated•16 years ago
|
Hardware: Macintosh → All
Reporter | ||
Comment 13•16 years ago
|
||
I created a build from the official 3.0 sources with the patch from this bug and the patches from bug 435414 and the issue seems to be resolved!
Assignee | ||
Comment 14•16 years ago
|
||
I hope to push this to mozilla-central tomorrow, and then make an argument for drivers that we should take this for 3.0.1.
Status: NEW → ASSIGNED
Flags: wanted1.9.0.x? → blocking1.9.1?
Whiteboard: [has patch][has review][needs bug 435414] → [has patch][has review][can land]
Comment 16•16 years ago
|
||
This same behavior exists when the home folder is a SMB based share. We utilize the ability of the Mac to use our existing Windows Domain with home folders and the release version firefox 3 does not work with the home folders operating off of the domain resource.
Assignee | ||
Comment 17•16 years ago
|
||
Pushed to mozilla-central: http://hg.mozilla.org/mozilla-central/index.cgi/rev/c9b5882bf6f6 (In reply to comment #16) > This same behavior exists when the home folder is a SMB based share. We utilize > the ability of the Mac to use our existing Windows Domain with home folders and > the release version firefox 3 does not work with the home folders operating off > of the domain resource. Can you possibly test to see if this patch solves your issue? It'll be in tomorrows nighlies for 3.1.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has review][can land]
Target Milestone: --- → mozilla1.9.1
Assignee | ||
Updated•16 years ago
|
Attachment #324848 -
Flags: approval1.9.0.1?
Comment 21•16 years ago
|
||
FYI - I have tested the nightly for 080619 and this patch has solved the problems with AFP-mounted profile directories on our systems. Thanks for your help with fixing the issue.
Comment 22•16 years ago
|
||
FYI, the nightly build seems to have resolved the same issue on systems using smb-mounted profiles as well. Thanks for the community's quick turn around on this bug. Any ETA on getting it integrated into the current version 3 as a point release?
Comment 23•16 years ago
|
||
Assuming that the SQLite 3.5.9 update sticks, I believe the aim is to get this fixed for Firefox 3.0.1.
Assignee | ||
Comment 24•16 years ago
|
||
(In reply to comment #23) > Assuming that the SQLite 3.5.9 update sticks, I believe the aim is to get this > fixed for Firefox 3.0.1. That is the going plan - still waiting on blocking status for sqlite and this bug.
Assignee | ||
Comment 25•16 years ago
|
||
verified per comment 21 and comment 22 Thanks guys.
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 27•16 years ago
|
||
I'd *really* like to see this get in for 3.0.1. This fix has been landed in mozilla-central for a little more than ten days, with no noticeable performance regressions. The fix has been verified to fix the issues with *both* AFP and smb-mounted profile folders (comment 21 and comment 22 respectively). I have a red-eye flight tonight, so I don't know how much I'm going to be around tomorrow. If I'm not, can a driver please make sure someone else lands this if I'm not around?
Comment 29•16 years ago
|
||
Comment on attachment 324848 [details] [diff] [review] v1.0 a=beltzner, sorry for losing track of this
Attachment #324848 -
Flags: approval1.9.0.1? → approval1.9.0.1+
Updated•16 years ago
|
Flags: blocking1.9.1?
Flags: blocking1.9.1+
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1+
Comment 30•16 years ago
|
||
Checking in db/sqlite3/src/Makefile.in; /cvsroot/mozilla/db/sqlite3/src/Makefile.in,v <-- Makefile.in new revision: 1.36; previous revision: 1.35 done
Keywords: fixed1.9.0.1
Comment 31•16 years ago
|
||
updating status whiteboard to verified per comment 25
Keywords: fixed1.9.0.1 → verified1.9.0.1
Assignee | ||
Comment 32•16 years ago
|
||
Had to back this out for bug 442949
Assignee | ||
Comment 35•16 years ago
|
||
We can try this again when we upgrade to the latest sqlite...
Comment 36•16 years ago
|
||
Made me back-out the migration to server-based home directories for our Mac network. :-(
Comment 37•16 years ago
|
||
v3.0.1 release appears to resolve issue on SMB network volumes.
Comment 38•16 years ago
|
||
Yes, the updated SQLite was only backed out of the trunk (Firefox 3.1). It was left on the Firefox 3.0.x branch.
Assignee | ||
Updated•16 years ago
|
Whiteboard: [needs sqlite upgrade]
Comment 39•16 years ago
|
||
Adding keywords; this is fixed on the 3.0.x branch (as in, it the sqlite upgrade wasn't backed out there) so we need to reflect that.
Keywords: fixed1.9.0.1,
verified1.9.0.1
Updated•16 years ago
|
Keywords: fixed1.9.0.1
Comment 40•16 years ago
|
||
Issue unresolved on 10.4 ppc 10.5 intel connecting to OSX 10.4 afp server and 10.5 afp server using nightly release 3.1a2pre. Can regularly reproduce small window that fails to respond, get "Another copy of FF is currently open", or goes directly to Mozilla Bug Report. After deleting all FF application support as well as removing the .parentlock file the errors continue to reoccur and ultimately after multiple failures mentioned above FireFox fails to respond at all. We are a school district maintaining network home directories for more than 2000 users half of which depend on FF. Please update status.
Assignee | ||
Comment 41•16 years ago
|
||
(In reply to comment #40) > Issue unresolved on 10.4 ppc 10.5 intel connecting to OSX 10.4 afp server and > 10.5 afp server using nightly release 3.1a2pre. Can regularly reproduce small > window that fails to respond, get "Another copy of FF is currently open", or > goes directly to Mozilla Bug Report. After deleting all FF application support > as well as removing the .parentlock file the errors continue to reoccur and > ultimately after multiple failures mentioned above FireFox fails to respond at > all. We are a school district maintaining network home directories for more > than 2000 users half of which depend on FF. Please update status. You shouldn't be using alpha or nightly builds for more than 2000 users. This is fixed in 3.0.x, but not in 3.1.x. Had you read the bug, you wouldn't need me to update the status for you.
Status: REOPENED → ASSIGNED
Comment 42•16 years ago
|
||
I'm sorry that I left out the fact that we are experiencing the error on 10.4 and 10.5 intel and ppc clients connected to home directories on OSX 10.4 and 10.5 afp servers using FF 3.0.1. I tried your alpha as a Hail Mary last resort on a single machine with a single user. FF 3.0.1 is the current version on 1500 computers and we are still experiencing the issues the update claims to have resolved.
Comment 43•16 years ago
|
||
UPDATE COMMENT #40 ISSUE UNRESOLVED! On either a 10.4 ppc 10.5 intel computer connecting to either a OSX 10.4 afp or 10.5 afp server using FF 3.0.1. I also tried FF 3.1a2pre on a single client with a single user without success. We had the parentlock issue with 2.x but this is MUCH WORSE AND IS A CRITICAL ISSUE! Using 3.0.1 I can regularly reproduce the small window that fails to respond. I get "Another copy of FF is currently open", or it goes directly to the Mozilla Bug Report. After deleting all FF application support as well as removing the .parentlock file the errors continue to reoccur and ultimately after multiple failures mentioned above FireFox fails to respond at all. We are a school district maintaining network home directories for more than 2800 users who depend on FF. PLEASE HELP!! Please reopen the ticket. Thanks
Comment 44•16 years ago
|
||
While I did have this issue with FF 3.0.0, FF 3.0.1 seems to work fine for us using OS X 10.5.4 on both PPC and Intel clients with home directories on an Intel XServe running OS X Server 10.5.4.
Comment 45•16 years ago
|
||
Marcia can help reproduce the problem in c44. But she needs some help from IT to setup AFP. Matthew- Can someone from your team help with this?
Comment 46•16 years ago
|
||
Sean, can you help out here?
Comment 47•16 years ago
|
||
I run a test on my two machines at home with To get it to work I shared my public folder on my Mac Mini via AFP. After that I created a fresh profile on my MacBook and selected the connected AFP-folder as target. Starting Minefield afterwards results in an immediately shutdown. Opening the folder only shows following files: lrwxr-xr-x@ 1 henrik staff 14 23 Aug 01:13 .parentlock -> 127.0.0.1:2570 -rw-r--r--@ 1 henrik staff 0 23 Aug 01:12 127.0.0.1:2555 -rw-r--r--@ 1 henrik staff 0 23 Aug 01:13 127.0.0.1:2570 This happens for each version of Firefox (Fx2, Gran Paradiso, Minefield). Is this another issue which should be filed as its own bug? Due to this issue I'm not able to follow the given STR. Or do I have to place the whole OS X user profile on a AFP share?
Assignee | ||
Comment 48•16 years ago
|
||
Hmm, that seems like it is a different issue (I'd expect more files there by default). Maybe that's what comment 43 is hitting?
Comment 49•16 years ago
|
||
As #43 stated, this is a critical issue for us and basically makes FF unusable. Another piece of information that he forgot to give you is that backgrading to 2.x, didn't resolve the problem even though we hadn't seen the current "can't fix it by deleted the parentlock problem" until we upgraded to 3.0. Last year we had a lot of problems with FF as the students forgot to close the application before logging off the computer. This action would abort the session with the server will FF was still open thus creating the firefox is already open problem. The resolution for this was to log on the server and use Onyx to find the parent lock folder, delete, and then the user was good, (at least until they did it again). To counter that problem we developed a script for the Macs that forces a shutdown of all applications on log off and that seemed to work very well. This year we were having some problems with another application and were requested by the vendor to upgrade FF to 3.x and thus the new set of problems occurred. SO, in our attempts to clear off the references to FF in the student directory we are obviously missing something otherwise we could at least temporarily fix the problem. If possible, please respond with all of the user based files that we should be looking for in our attempts to clear out and start over. <end> I'm not able to create a profile at least. Only the given files are located there. Does that also happen on your side or do you have a running profile and are all necessary files are stored on the AFP share? Thanks, Henrik <end> Henrik, When using Apple home directories, all of the user based information including the profile is located on the file server but the actual application is still located on the local computer.
Assignee | ||
Comment 51•16 years ago
|
||
Pushed to mozilla-central: http://hg.mozilla.org/mozilla-central/rev/b2d48e54c537
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 16 years ago
Flags: in-litmus?
Keywords: qawanted
Resolution: --- → FIXED
Whiteboard: [needs sqlite upgrade]
Assignee | ||
Updated•16 years ago
|
Target Milestone: mozilla1.9.1 → mozilla1.9.1b1
Assignee | ||
Comment 52•16 years ago
|
||
We have to backout bug 449443 because we have to backout bug 456910 because of a Tp regression, which means we need to back this out :(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•16 years ago
|
Priority: -- → P1
Assignee | ||
Updated•16 years ago
|
Priority: P1 → P2
Assignee | ||
Updated•16 years ago
|
Target Milestone: mozilla1.9.1b1 → mozilla1.9.1
Does the truncate journal mode patch in 3.6.4 address this issue, or is a separate solution required? Even if a config option were necessary, all the schools I work with would gladly jump through the hoop and take the performance penalty to be able to use Firefox (it's effectively unusable in an OSX Server shop).
Assignee | ||
Comment 54•16 years ago
|
||
(In reply to comment #53) > Does the truncate journal mode patch in 3.6.4 address this issue, or is a > separate solution required? Even if a config option were necessary, all the > schools I work with would gladly jump through the hoop and take the performance > penalty to be able to use Firefox (it's effectively unusable in an OSX Server > shop). If by this issue you mean this bug, upgrading will allow us to enable it. If you are on Firefox 3.0.x though, you already have this fix and you should file another bug about any issue you might be having.
Assignee | ||
Comment 55•16 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/fafaf721f03d
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.9.1 → mozilla1.9.1b2
Updated•16 years ago
|
Keywords: fixed1.9.1
Comment 56•16 years ago
|
||
I know it's been a few months, but this bug is not completely fixed in similar server/profile environments. Our Macs run in a similar way to AFP--we use a Windows Server and Active Directory. A SMB connection is used for accessing the user's system profile live over the network. Before this bug fix was implemented, we had the exact same problem as AFP users. Non-functional FF. After the bugfix was implemented, FF would work for the first run, or a new profile, but after logging out and logging back in, Firefox would forget its Bookmarks and other personal settings, and the back/forward buttons would sometimes be nonfunctional. I have been forced to revert back to Firefox 2--I would assume that either nobody is really using Firefox in an SMB-hosted profile environment, or there is another unresolved bug that I can't find.
Assignee | ||
Comment 57•16 years ago
|
||
(In reply to comment #56) > Before this bug fix was implemented, we had the exact same problem as AFP > users. Non-functional FF. After the bugfix was implemented, FF would work for > the first run, or a new profile, but after logging out and logging back in, > Firefox would forget its Bookmarks and other personal settings, and the > back/forward buttons would sometimes be nonfunctional. It sounds to me like your file system is not releasing the lock when we (sqlite) tell it to. We can't really do anything about that it turns out.
Comment 58•15 years ago
|
||
(In reply to comment #56) > Our Macs run in a similar way to AFP--we use a Windows Server and Active > Directory. A SMB connection is used for accessing the user's system profile > live over the network. Alex, you should have a look at bug 309323.
Updated•15 years ago
|
Keywords: verified1.9.1
Updated•15 years ago
|
Keywords: fixed1.9.1
Comment 59•15 years ago
|
||
Devin or any other one, who had problems with AFP, can you please give us feedback if the given patch has been resolved your issue? Thanks!
Updated•15 years ago
|
Keywords: verified1.9.1
Comment 60•15 years ago
|
||
sorry for the inconvenience. i meant to detect any bugs before the branch merge that were still RESO fixed, but had a verified1.9.1 keyword next to them.
Keywords: verified1.9.1
Comment 61•15 years ago
|
||
this should be marked fixed1.9.1 and still needs to be verified on 1.9.1branch
Keywords: verified1.9.1 → fixed1.9.1
Comment 62•15 years ago
|
||
This status should be changed to "open" I've just tested 3.0.7 and can confirm that the issue is NOT resolved. This issue is very hard to track in our environment because it is inconsistent where one user will have this problem and another will not.
Assignee | ||
Comment 63•15 years ago
|
||
(In reply to comment #62) > This status should be changed to "open" I've just tested 3.0.7 and can confirm > that the issue is NOT resolved. This issue is very hard to track in our > environment because it is inconsistent where one user will have this problem > and another will not. You should file a new bug with the details of the issue you are seeing because this bug has been verified as fixed, and the code has not changed.
Comment 64•15 years ago
|
||
(In reply to comment #63) > (In reply to comment #62) > > This status should be changed to "open" I've just tested 3.0.7 and can confirm > > that the issue is NOT resolved. This issue is very hard to track in our > > environment because it is inconsistent where one user will have this problem > > and another will not. > You should file a new bug with the details of the issue you are seeing because > this bug has been verified as fixed, and the code has not changed. (In reply to comment #63) > (In reply to comment #62) > > This status should be changed to "open" I've just tested 3.0.7 and can confirm > > that the issue is NOT resolved. This issue is very hard to track in our > > environment because it is inconsistent where one user will have this problem > > and another will not. > You should file a new bug with the details of the issue you are seeing because > this bug has been verified as fixed, and the code has not changed. I have a related problem in FF 3.0.8 and Beta. See Bug 489227.
Comment 65•15 years ago
|
||
I've found a similar issue upgrading from 3.0.10 to 3.0.11 (See <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=497792">Bug 497792</a>).
Reporter | ||
Comment 66•15 years ago
|
||
Confirmed. Firefox 3.0.11 is showing the same behavior that I originally created this report for.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 67•15 years ago
|
||
The particular issue this bug was to fix was fixed and verified. Please open a *new* bug if you are still seeing issues over the network as it's not this bug.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 15 years ago
Resolution: --- → FIXED
Comment 68•15 years ago
|
||
OK, I thought so. Which is why a new bug was opened. See: Bug 497792
See Also: → https://launchpad.net/bugs/237970
You need to log in
before you can comment on or make changes to this bug.
Description
•