Closed Bug 417037 Opened 16 years ago Closed 15 years ago

mozStorage chokes on databases over AFP

Categories

(Toolkit :: Storage, defect, P2)

All
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla1.9.1b2

People

(Reporter: tsteiner, Assigned: sdwilsh)

References

Details

(4 keywords)

Attachments

(2 files)

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
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.
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).
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.
Component: General → Places
Keywords: regression
QA Contact: general → places
Version: unspecified → 3.0 Branch
confirming, from the multiple independent confirmations above.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.0.x?
Flags: blocking1.9.0.1?
Flags: blocking-firefox3?
This may be fixable, but might be a bit slower too - see http://www.mail-archive.com/sqlite-users@sqlite.org/msg34473.html
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
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: nobody → sdwilsh
Component: Places → Storage
Flags: blocking-firefox3-
Product: Firefox → Toolkit
Version: 3.0 Branch → Trunk
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
Summary: Address and Search bars not accepting input with profile on AFP Home directory → mozStorage chokes on databases over AFP
Attached patch v1.0Splinter Review
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)
Attachment #324848 - Flags: review?(benjamin) → review+
QA Contact: places → storage
Whiteboard: [has patch][has review][needs bug 435414]
Hardware: Macintosh → All
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!
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]
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.
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
Attachment #324848 - Flags: approval1.9.0.1?
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.
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?
Assuming that the SQLite 3.5.9 update sticks, I believe the aim is to get this fixed for Firefox 3.0.1.
(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.
verified per comment 21 and comment 22

Thanks guys.
Status: RESOLVED → VERIFIED
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 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+
Flags: blocking1.9.1?
Flags: blocking1.9.1+
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1+
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
updating status whiteboard to verified per comment 25
Had to back this out for bug 442949
Status: VERIFIED → REOPENED
Keywords: verified1.9.0.1
Resolution: FIXED → ---
We can try this again when we upgrade to the latest sqlite...
Depends on: 445042
No longer depends on: 435414
Made me back-out the migration to server-based home directories for our Mac network. :-(
v3.0.1 release appears to resolve issue on SMB network volumes.
Yes, the updated SQLite was only backed out of the trunk (Firefox 3.1). It was left on the Firefox 3.0.x branch.
No longer depends on: 445042
Depends on: 449443
Whiteboard: [needs sqlite upgrade]
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.
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.
(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
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.
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
Keywords: qawanted
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. 
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?
Sean, can you help out here?
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? 
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?
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.
Pushed to mozilla-central:
http://hg.mozilla.org/mozilla-central/rev/b2d48e54c537
Status: ASSIGNED → RESOLVED
Closed: 16 years ago16 years ago
Flags: in-litmus?
Keywords: qawanted
Resolution: --- → FIXED
Whiteboard: [needs sqlite upgrade]
Target Milestone: mozilla1.9.1 → mozilla1.9.1b1
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 → ---
Priority: -- → P1
Priority: P1 → P2
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).
(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.
http://hg.mozilla.org/mozilla-central/rev/fafaf721f03d
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.9.1 → mozilla1.9.1b2
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.
(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.
(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.
Keywords: verified1.9.1
Keywords: fixed1.9.1
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!
Keywords: verified1.9.1
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
this should be marked fixed1.9.1 and still needs to be verified on 1.9.1branch
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.
(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.

(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.
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>).
Confirmed.  Firefox 3.0.11 is showing the same behavior that I originally created this report for.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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 ago15 years ago
Resolution: --- → FIXED
OK, I thought so. Which is why a new bug was opened.  See: Bug 497792
You need to log in before you can comment on or make changes to this bug.