Posted: Thu Nov 04, 2010 9:36 am Post subject: Weird files in root
I've suddenly started getting weird files appearing in my root folder. They're called key3.db, cert8.db, & secmod.db - I assumed they were something to do with Firefox, but an app that determines what app has what file open told me that soffice.bin is using them.
Any thoughts? The first lot turned up a few days ago, and I deleted them. The most recent ones are all from 7.02 this morning. I have no idea what triggered their creation yet. I'm keeping a close eye on that folder from now on!
Posted: Thu Nov 04, 2010 9:45 am Post subject: Re: Weird files in root
yoxi wrote:
I've suddenly started getting weird files appearing in my root folder. They're called key3.db, cert8.db, & secmod.db - I assumed they were something to do with Firefox, but an app that determines what app has what file open told me that soffice.bin is using them.
These 3 files have been in Firefox, Mozilla, and Netscape since the 1990s. Since the OpenOffice.org uses the Mozilla code to provide JavaScript support and to manage macro security, it is conceivable that they were dropped there by OpenOffice.org or NeoOffice.
I would recommend deleting them and see if they reappear after using NeoOffice. The most recent versions of NeoOffice should write such files only within your Home folder so if they reappear in the root folder, then there is a bug in NeoOffice's underlying OpenOffice.org code that we might be able to fix.
Okay, I just restarted my mac, launched NeoOffice (no new files) - and then opened a spreadsheet (which took longer than it should have done), and suddenly there are the new files in root again. The delay in opening the file comes after it displays the initial frame the window is going to be painted in, and before it paints the 'background colour'.
Deleting the files, quitting, relaunching NeoOffice, and opening a spreadsheet file recreates the files all over again. It also seems to be taking an unusually long time to open and draw the file even once NeoOffice is already up and running (I'm on a fast new 3.33GHz iMac).
Is there anything I can send you to help you track this bug down?
Deleting the files, quitting, relaunching NeoOffice, and opening a spreadsheet file recreates the files all over again. It also seems to be taking an unusually long time to open and draw the file even once NeoOffice is already up and running (I'm on a fast new 3.33GHz iMac).
Sounds to me like your spreadsheet was macros in it and/or it is loading date from a remote website or data source.
If you quit NeoOffice, delete the files, and open a new, empty spreadsheet, do these files appear? If not, do they appear only when you open a specific spreadsheet?
BTW, I moved this forum topic to the NeoOffice Support forum since we are troubleshooting a bug.
Sounds to me like your spreadsheet was macros in it and/or it is loading date from a remote website or data source.
More specifically, is your spreadsheet querying an LDAP address book or database? I found the Mozilla code and its LDAP querying code is what creates those files. Also, since most LDAP servers is on a different machine, that may account for the slowness in your spreadsheet: your spreadsheet is connecting to a remote LDAP database and fetching a bunch of data over the network.
BTW, the reason that the files are created in your "/" root folder appears to be caused by a bug in the Mozilla code, not the OpenOffice.org code. The Mozilla code creates those files in the "current working directory" of an application. Since Mac OS X sets the default working directory to "/" when you launch an application, the Mozilla code stupidly creates those files in "/".
Joined: Jun 11, 2006 Posts: 481 Location: Great Britain
Posted: Fri Nov 05, 2010 8:58 am Post subject:
pluby wrote:
Since Mac OS X sets the default working directory to "/" when you launch an application, the Mozilla code stupidly creates those files in "/".
Just out of interest, what behaviour would that cause if the spreadsheet was opened by a user without administrator privileges? It's not the done thing these days, but I keep a day-to-day user account and a separate admin account.
Just out of interest, what behaviour would that cause if the spreadsheet was opened by a user without administrator privileges? It's not the done thing these days, but I keep a day-to-day user account and a separate admin account.
I do not know. I cannot even reproduce the behavior that yoxi so I do not know what his spreadsheet is supposed to do.
In any case, my "/" folder has the following permissions which will not allow even administrators to write to the "/" folder so if your spreadsheet needs to query an LDAP server and, like me, the Mozilla code cannot write to "/", then I assume that Mozilla's LDAP querying will fail:
Joined: Jun 11, 2006 Posts: 481 Location: Great Britain
Posted: Fri Nov 05, 2010 9:51 am Post subject:
pluby wrote:
permissions which will not allow even administrators to write to the "/" folder
Ah, true. The difference is that administrators are in the sudoers list. That being the case, I would expect an attempt to write to the root folder either to cause a prompt for an administrator's password to appear, or to just fail immediately.
If those files can be written without any password prompt, that would mean either that yoxi's root folder has incorrect permissions or that the process creating the files is running as root (not a good thing).
Ah, true. The difference is that administrators are in the sudoers list. That being the case, I would expect an attempt to write to the root folder either to cause a prompt for an administrator's password to appear, or to just fail immediately.
It will fail immediately. Trying to write to a file writable only by root does not magically invoke GUI dialogs. You are confusing Finder functionality with Unix file API functions. Unix file open() function only returns an integer: a file handle or -1 for an error.
djpimley wrote:
If those files can be written without any password prompt, that would mean either that yoxi's root folder has incorrect permissions or that the process creating the files is running as root (not a good thing).
yoxi's root folder has incorrect permissions. NeoOffice is not running as root as the Unix user ID is checked in NeoOffice's main() function and if it is root, NeoOffice will exit and print an error message to the console. You will not even get to the splash screen in that case. This "cannot run as root" restriction has been in place since at least 2004.
Joined: Jun 11, 2006 Posts: 481 Location: Great Britain
Posted: Fri Nov 05, 2010 10:57 am Post subject:
pluby wrote:
Trying to write to a file writable only by root does not magically invoke GUI dialogs.
Understood. I was unsure at what level OS X authentication services gets involved in this kind of thing.
pluby wrote:
yoxi's root folder has incorrect permissions.
I just checked my root and discovered - after assuming that rwxr-xr-x was obviously the correct setting - that mine is actually set to:
Code:
drwxrwxr-t 34 root admin
I have the sticky bit set. I migrated to this Mac with a fresh install of Leopard, now on Snow Leopard. Disk Utility's "verify permissions" does not complain about my root folder. If this setting is normal for Snow Leopard then it would explain why yoxi can create those files in his root folder, so long as he is using an account with administrator privileges. Sorry to take the conversation off on a tangent, just wanted to make sure my idle speculation didn't unnecessarily panic yoxi!
If possible, I would like to see if yoxi can tell us what in his spreadsheet triggers the creation of these files. Regardless of whether you have writable access to the root folder or not, writing to the root folder is just not a good thing so I would like to see if there is a simple thing in the OpenOffice.org code (such as an environment variable) that will force the Mozilla code to create these files within your NeoOffice user preferences folder.
Sorry, been away in London celebrating my birthday .
Well, this is interesting. It's just this one spreadsheet that behaves like this (which I open daily). It's a native ods file created by NeoOffice in the spring, has two sheets and has no links to anything outside it whatsoever, not even links between the two sheets. But opening this file creates those files in root, and no other file I open in NeoOffice seems to do that.
The only thing that's unique about this spreadsheet is that it uses conditional formatting, as far as I can see there's nothing else unique about it.
I do remember having a crashing problem a while back that this file was a bystander in, so maybe something in it has got messed up. The simple answer would be to copy and paste the contents into a new file and see what happens.
...
Well, I pasted the data into a new spreadsheet, and that opens fine without triggering the root files. And then I saved the old file with a new name - and now the old one won't open at all! Beats the hell out of me - the permissions on the two files are exactly the same. The king is dead, long live the king.
I'm baffled - I copied a backed-up version of the dodgy file back to my folder and it still did the bad thing. Then I moved it to a temporary folder to zip it so you can play with it - and it doesn't do the bad thing from there. So I moved it back to the original folder, and it still doesn't do the bad thing.
So here's a freshly restored backup version that still does the bad thing - note that it also takes a long time to switch between sheets on this file. I hope you have fun playing with it, when you have a moment.
Thank you for the sample file. The bad news first: I could not reproduce the creation of those *.db files on my machine even when I made my machine's root folder writable by all users.
But the good news is that I found what is causing the slowness and, most likely, what triggers the creation of those *.db files: you have an image in your spreadsheet that is set to be fetched from a secure website.
It took me a couple hours to find this image as it is not visible in your spreasheet. But if you remove it using the following steps, does the speed improve for you?:
1. Select the View :: Navigator menu
2. In the Navigator window that appears, expand the Graphics item. You should see a subitem that is a URL beginning with "https://".
3. Drag that URL to an empty cell in your spreadsheet. This should remove it from the Graphics item in the Navigator window.
4. Select the cell that you dragged the URL to and press the Delete key to delete the URL.
I'll be damned. That must have sneaked in when I pasted what I thought was just a couple of columns of text out of a firefox webpage a while back. I certainly never intended any images or urls to land in the spreadsheet, and I thought I'd pasted special as unformatted text each time.
Sorry for the whole wild goose chase - and thanks for finding the culprit; I never have the Navigator window open, so I'd never have spotted that.
Sorry for the whole wild goose chase - and thanks for finding the culprit; I never have the Navigator window open, so I'd never have spotted that.
Neither do I. I only opened the navigator window once I had completely removed all content and formatting from both sheets and the slowness was this still there. At least I now know to checking the Navigator can be a useful tool for troubleshooting unexplained spreadsheet slowness issues.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum