~/.MCXLC file and 10.2.4

hmm, yep, here, too.

it's not a valid roman numeral sequence

Yes, at first glance, I thought about a Roman numeral too.

Google comes up with a document about: Page 1
New Compact Mode Converters for SLAC RF Pulse
Power Compression System...
and then mentions that a transition and mcxlc conversion system needs to be developed.

Could it have been sent by the radiation gods?

Pure speculation but could it be something to extend the range or reliability of either Bluetooth or AirPort. Not this particular file of course which looks to be an empty unix style preference file. Which probably eliminates AirPort.

RF Pulse Power Compression sounds like it could either increase signal strength without exceeding power limits or allow reduced power while still maintaining signal strength, which might be usefull for laptops. But all my RF chops are really rusty (early 1970's) and never went much beyond low power longwave pcm (15 - 20 feet range) stuff to begin with.:p

Willy

Very interesting Willy. Thanks for your take on it. At least you have some RF chops. :)

I do find it odd that only three of us confirm having this file on our rigs. Maybe nobody wants to peruse their $HOME to see or they just don't care. I suppose I would understand the later since it's zero bytes anyway and probably means nothing much.

I say, "Ohmmm", to the radiation gods. ;)

And, hey, I just noticed a not-so-grumpy-Willy! I guess there's no smoke coming from your G-85 today. :D

Maybe nobody wants to peruse their $HOME to see or they just don't care.

I didn't care...until you said that!

:)

Yep, that file is here in my home folder too.

Here too...

thach

Just haven't put any paper in it (G85) since I printed out the Reason manual.(270+ color pages)


I don't have an AirPort or Bluetooth so my comments are still just speculation.

I have a Reason not to be grumpy now if only I had a Rosegarden.
Willy

this file exists on my rig.

perhaps people dont see the file because the dont ls -al

Thanks for the confirms guys. I figured that it must exist on most rigs of late. What it's actually for, who knows?

WillyT,

I wonder what you are using for your printing, scanning, copying and faxing now then?

Also, I don't have airport or bluetooth either although the 10.2 version of the software is installed without any updates. Your speculation sounds reasonable enough.

Spring is just around the corner and maybe a rose garden is in the making? Sometimes you have to look around and smell the roses to avoid the grumpies. :cool:

Got one here too. Dated 13th Feb. That would be about the time I installed 10.2.4 I think...

I have it, too. Keeps coming back. Meh.


-/-

13 feb here also, it appeared after up'ing to 10.2.4

deleted it yesterday. hasn't returned.

monitored fs_usage for it for a while - gave up.

me thinks Mikey-San's is more romantically entangled. meh, indeed.

10.2.4 server has it as well.

-rw-r--r-- 1 eagleyes staff 0 Feb 24 18:41 .MCXLC

It is not on my other server which still has 10.2.2 (yeah I am out of date, but it take to much work to update the other server for every little update)

Whatever the hell it is, no app seems to care much about it. After this:

% ln -s /dev/null ~/.MCXLC

Nothing's started behaving badly.

Hmm. We'll find out, I guess! :D


-/-

Well, look at this:

/Library/Preferences/com.apple.MCX.plist
/System/Library/LoginPlugins/MCX.loginPlugin

So ... Thoughts? Does anyone think this might be related?


-/-

Well, look at this:
/Library/Preferences/com.apple.MCX.plist
/System/Library/LoginPlugins/MCX.loginPlugin
So ... Thoughts? Does anyone think this might be related? Yes - definitely related. If you use the 'strings' command to look inside the MCX binary file that is under /System/Library/LoginPlugins/MCX.loginPlugin/Contents/MacOS/, you will see that it refers to ".MCXLC"

This MCX stuff seems to be related to workgroup management and LDAP.
There is mention of MCX & LDAP on the (German language) page http://www.bresink.de/jaguarbuch.html

and if you use (Developer tool) Interface Builder to open up the nib file that is under /System/Library/LoginPlugins/MCX.loginPlugin/Contents/Resources/, you will see that it appears to be a preference pane for workgroup management.

Nice work guys. Thanks for figuring it out.

Well I might have overstated there... Here's the details:

Machine started acting oddly - most notably the Finder crashing when trying to open certain folders, including my Applications and Home directory (directory will be abbreviated as "dir" henceforth) among others. The crash was (is) consistent. Also, applications began crashing, notably LaunchBar, SNAX, and WorkStrip.

Re-started to check for "computer hoo-doo weirdness" which did nothing. Deleted the .MCXLC file from my home dir, the crash stopped happening for that dir. Crash still occurs for Applications dir and (I assume from other application behavior) application files which reference/index the filesystem. No other applications seem to crash except those who make use of the information stored in the Applications dir. Oddly enough, the Terminal is not affected; I can browse using standard commands such as "ls" and variants, and BBEdit Lite could open files from within the home dir without crashing but crashes out when trying to do so from within the Apps dir.

I've checked the contents of the Apps dir (using the Terminal) and haven't found any other items that aren't standard for the folder except the file ".mtd-flag" which, along with the ".DS_Store" file I've deleted with no change (Finder still crashes when trying to browse Apps dir., same for BBEdit Lite)

Ugh. I will post more later. Not happy.

I have no clue what's happening - but I've logged in as another user and the Finder still crashes on listing of the Apps dir. Nothing's listed in the .Localized file in the Apps dir, however BBEdit still crashes when I try to browse the dir to open files so I am not sure I've got the correct .Localized file because I have to specify an absolute path and filename to open it...

??? Clueless here ???

Any help is appreciated.

Edit:
PS: When I try to do a find for anything in the Apps dir (i.e. hit command+f, set where to search as everywhere and type in "Safai" as name then press enter) the Finder crashes also. Thought that might be of importance.

10.2.6
Airport = yes
Bluetooth = no

My account = no .MCXLC file
My guest account =
-rw-r--r-- 1 guest staff 0 Apr 4 20:48 .MCXLC

Now Dangerously Close to Off Topic:

Booted from 10.2 Install CD; repaired disk permissions + verified disk. Verification came back OK, permissions (hereafter referred to as perms) had much to do, including setting the perms on the Applications folder to some other goodness. However, no change. LaunchBar still crashes on launch, WorkStrip X doesn't even launch.

Just now, while browsing through boot volume, Finder crashed again, this time was unique because the contents of the dir had already been listed when the crash occurred. This is the first time I've noticed this. Seems to happen consistently now when browsing root of boot disk with invisible files visible; have not tried without invisible files visible. This does not happen if I go to the "Computer" dir, and view as list, then turn down the arrow for the boot volume. This leads me to believe that the default .DS_Store file is corrupt or just plain wrong. I replaced the contents of the .DS_Store file from this dir with the contents from my home dir; same result (crash after a few moments.) Deleted contents of .DS_Store file, no crash. Woo Hoo!

Luck doesn't hold up when attempting the same for the Apps dir; replaced with blank text file named ".DS_Store" with no change (Finder still crashes on listing of the Apps dir.)

BTW, Noticed some time back that when I use the "Terminal Here" contextual menu, the Finder crashes. Don't know if this is related or not - will test later somehow.


On a more directly relevant note, found this in /Library/Preferences/com.apple.MCX.plist:


[?xml version="1.0" encoding="UTF-8"?]
[!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd"]


MCX_PreferencesAreManaged
NO




(all brackets have replaced the xml markup brackets, whatever they're called, to ensure the browser doesn't confuse the tags with HTML.)

I do have a D-Link Bluetooth adapter, but no Airport. I've also got Mac OS X v10.2.6, and the .MCXLC file is back now with no contents when opened with BBEdit Lite.

Ugh Again.

EDIT:
The problem with the Apps dir doesn't seem to affect sub-dirs, i.e. the Adobe Illustrator folder displays with no problem. I just tried launching LaunchBar again, quit (as usual) and I think it took the dock with it this time.

[edit: fold -mt]

Just got a (now consistent) crash when trying to set global view options.

Also seems to occur when getting info on certain dirs, manifested when trying to copy icon from Documents dir to an alias.

Forget it. Re-installing OS. Cause of crash seems to be creeping... I can't find it. Cannot even work on system to troubleshoot at this point.

Yeah, re-installing the OS does wonders for problems. Good luck to the rest of you!

PS: Did a re-install with preservation of users, so most of my preferences and such survived intact. Just FYI, in case someone else has similar problem.

(EDIT: Added info on re-install.)

I found out what .MCXLC does the hard way! It's an account-is-logged-in-flag.

This empty file is locked open when a user logs in. When they log out, it is closed.

When a network user tries to log on twice on two of our lab machines, it kindly tells them they are already logged in. This is good, because otherwise there could be apps trying to read and write to the same Library files in the homedir at the same time.

HOWEVER, if a user doesn't log off (a network problem or if the Finder locks up or whatever and they restart the mac), then they can never log on again! They get the already logged on message! The file is locked in use - the only way to get rid of it is for us log in as an admin on the box itself (in person or via RDC - it is a win2k Server running ExtremeZ-IP) and delete it.

While there should be a single-login locking system, the current method stinks.

Originally posted by websterb
I found out what .MCXLC does the hard way! It's an account-is-logged-in-flag.

This empty file is locked open when a user logs in. When they log out, it is closed.
Huh? That's not what I show:
[gatorparrots:~]$ GetFileInfo .MCXLC
file: ".MCXLC"
type: ""
creator: ""
attributes: aVbstclinmed
created: 05/20/2003 07:59:11
modified: 05/20/2003 07:59:11
[gatorparrots:~]$ ls .MCXLC
0 -rw-r--r-- 1 staff 0 May 20 07:59 .MCXLC

The file's creation date is May 20. Today is Sept 4 and I only have an uptime (and GUI login time) of only one day. Also, the file only has one unusual attribute: it's not locked, but it is invisible. Somehow this doesn't jibe with your explanation.

$ getfileinfo .MCXLC
file: ".MCXLC"
type: ""
creator: ""
attributes: aVbstclinmed
created: 02/26/2003 14:51:09
modified: 02/26/2003 14:51:09

Well deleting it lets our users log in again.

I don't think it gets deleted on logout, but it's status changes. At login the system opens the file (creating it if it's not there) and at logout the system closes the file. It never actually writes anything TO the file. If the file is already open (in use) then it assumes you're trying to log in with the same account twice. For local users you might be allowed to delete it, but for network users (on our setup), any attempt to delete it when a user has not logged off correctly just results in an error because the server considers the file still 'in use' (unless you are logged in as admin on the server itself) .

That's what I experience - I've fixed 5 stuck accounts in the last month or so on 10.2.6.