March 2008 - Xquartz-dev - lists.macosforge.org

Re: [Xquartz-dev] Recovered files (font cache) issue in users's trash can
by Sierk Bornemann 12 Mar '08

12 Mar '08

Am 26.02.2008 um 22:49 schrieb Sierk Bornemann: > Since weeks, I have a problem with the font cache under Leopard > (only if logged-in as user -- logged-in as admin, the problem > doesn't occur), and I can't see the cause or how to solve the problem. > > System: > MBP 17“, Leopard (currently 10.5.2) > Latest XQuartz from http://trac.macosforge.org/projects/xquartz for > running Gimp properly. > The problem firstly occured between 10.5.1 and 10.5.2, and I don't > remember, if before or after switching from Apple's factory X11 to > the one of XQuartz's project, so I don't know, wether my problem has > anything to do with the XQuartz/X11 exchange or not. > > Regulary, being logged-in as user, my user account's trash can isn't > empty but contains of a directory "Recovered files", which itself > contains a directory like "ATS - 223553367". > This ATS-something-directory itself may contain files like > "annex_auth" (executable), "Local.fcache", > "System.fcache", "User.fcache" and "font". The files "annex_auth" > and "font" are always there, the others may be part of the folder > the next login. > Mostly, I can delete these files by emptying trash, but not every > single time. Sometimes (not everytime) the system denies that, > because one or all of theses files seem to be locked by the system > because of usage. > > I have tried everything to ged rid of these cache files, I have > deleted the font cache systemwide, for the user, I have made a "Safe > Boot", I have used the tool OnyX. The problem resists -- if I have > luck, the first boot after deleting font cache files seems to be OK, > but the second or third boot, the trash can of my user account > contains again these files. > > After searching around the net and not finding a solution, > I have logged-in as admin or root into the shell, went to /var/ > folders/kp/kpPJ1m.../-Caches- folder, and there is a folder > com.apple.ATS/, which seems to consist of exactly these fonts, which > are regulary in my trash can unter "Recovered files". The folder > com.apple.ATS/ and all below has the the owner/group of "admin/ > staff". Quite the same with the folder /var/folders/zz/zzzivh.../- > Caches-/System. There do exist the files "annex_auth" and "font". Is > this the system's user's font cache under Leopard (I have read, > something has changed on Leopard concerning that)? Both, files and > folders unter zzzivh.../ do have the owner/group "_atsserver/ > _atsserver". Deleting these files manually seems to resolve the > issue for exactly one time after logging-out and logging-in again or > rebooting. For the next time, I reboot or log-in as user, the user's > trash can again consists of "Recovered files" and these font cache > files. > > So, what the hell is the cause of this issue, and how can I get rid > of it? > Can anybody help me to solve this annoying issue? > Help would be appreciated. I have opened Activity Monitor from /Applications/Utilities to monitor the ATSServer process to get further information. I have done this for the system administrator (Administrator) and for the user MyName, selecting the process "ATSServer" and looking at further information (opened files and ports). This is the result for Administrator: --------------------------- / /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/ATS.framework/Versions/A/Support/ATSServer /private/var/folders/kp/kpPJ1mt.../-Caches-/com.apple.ATS/annex_aux /System/Library/Fonts/LucidaGrande.dfont /System/Library/Fonts/HelveticaNeue.dfont /System/Library/Fonts/Helvetica.dfont /System/Library/Fonts/Monaco.dfont /usr/lib/dyld /private/var/db/dyld/dyld_shared_cache_i386 /dev/null /private/var/folders/kp/kpPJ1mt.../-Caches-/com.apple.ATS/font /private/var/folders/kp/kpPJ1mt.../-Caches-/com.apple.ATS/annex_aux ->0x7e13330 --------------------------- And this is the result for the user MyName: --------------------------- / /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/ATS.framework/Versions/A/Support/ATSServer /Users/MyName/Library/Caches/TemporaryItems/ATS - 227034826/annex_aux /System/Library/Fonts/LucidaGrande.dfont /System/Library/Fonts/HelveticaNeue.dfont /System/Library/Fonts/Helvetica.dfont /System/Library/Fonts/Monaco.dfont /usr/lib/dyld /private/var/db/dyld/dyld_shared_cache_i386 /dev/null /Users/MyName/Library/Caches/TemporaryItems/ATS - 227034826/font /Users/MyName/Library/Caches/TemporaryItems/ATS - 227034826/annex_aux ->0x5aefcc0 --------------------------- What irritates me, is the fact, that Administrator uses the path / private/var/folders/kp/kpPJ1mt.../-Caches-/com.apple.ATS/ and user MyName uses the path /Users/MyName/Library/Caches/TemporaryItems/ATS - 227034826/ to store the font caches. Why arent they using the same path? Why does the folder /Users/MyName/Library/Caches/TemporaryItems/ exist, but not for Administrator (/Users/Administrator/Library/Caches/ TemporaryItems/)? Why is Administrator using the path under /private/var/folders/kp/ kpPJ1mt.../-Caches-/com.apple.ATS/ and not the path /Users/ Administrator/Library/Caches/TemporaryItems? Or, asked vice versa for user MyName: why is user MyName *not* using the path /private/var/folders/kp/kpPJ1mt.../-Caches-/com.apple.ATS/ but instead the path /Users/MyName/Library/Caches/TemporaryItems? It looks like, that the trashed folders and files in the "Recovered files" folder, when logged in as user 'MyName' are from /Users/MyName/ Library/Caches/TemporaryItems/ . But why? Any hints to solve the problem? -- Sierk Bornemann

1 0

Deadlock ine the OpenGL lib.
by Michał Majchrowicz 10 Mar '08

10 Mar '08

Hi. I wanted to ask if someone is working on this bug: http://trac.macosforge.org/projects/xquartz/ticket/74 I can now confirm that it also affects OpenOffice. I have reinstalled 10.5.2 system update and OO.org is working again. Please let me know if I can help with some testing or something like that. Regards Michal.

4 10

apple-dri for TOT mesa
by Pelle Johansson 08 Mar '08

08 Mar '08

Hi, I seem to have lost interest in making Apple-DRI work for the latest mesa, so I figured I'd share my work so far. It's a single diff, to avoid showing of my more embarrasing commits. :p It should probably still be considered a work in progress. It's pretty much bashed into place, without any finesse. What works: Apple-DRI works in direct mode, including window resizing. apple_dispatch.h is generated in a new way, avoiding the manual apple_disaptch.defs, which seemed like a PITA to maintain. What does not work: Indirect drawing is horribly broken. The indexes I put in apple_dispatch.h are wrong, and there's other problems too. I managed to crash the X server once by constantly resizing a GLX window (showing glxgears), but I haven't been able to reproduce it. There are a few #ifdef in autogenerated files, which is bad. To sum it up, the dispatch_stub functions and the ones using the GLint64EXT type are commented out, since it seems to be missing in OpenGL.framework. How to apply: Check out TOT mesa from git://anongit.freedesktop.org/git/mesa/mesa Apply diff. The diff is vs commit 02926a297782579591fc6b2b5f29b9d7709814da I hope someone will find it useful. -- Pelle Johansson

2 2

Xorg ports in MacPorts
by Adam Mercer 07 Mar '08

07 Mar '08

Hi In going though the MacPorts new submissions milestone I have ran into an issue regarding the xorg ports in MacPorts and wanted to get the input of the Xquartz developers on this issue. The standard MacPorts policy is to not use system libraries but depend on the appropriate port, this make supporting the port on different versions of Mac OS X much easier. There is however an expection, X. In the past if a port depended on X, the following dependency syntax was used: lib:libX11:XFree86, meaning to check for the libX11 library and if this was not found to build the XFree86 port. Now that Leopard has switched to xorg, I think its time to revisit this. But before I bring it on the MacPorts dev list I'd like to get your input, how would you like to see xorg support handled? Ben: As you originally wrote, and are down as the maintainer for, most of the xorg ports, how did you see this being handled? Cheers Adam

2 3