Re: VFS requirements for carbon/cocoa?
Re: VFS requirements for carbon/cocoa?
- Subject: Re: VFS requirements for carbon/cocoa?
- From: Quinn <email@hidden>
- Date: Wed, 29 Jun 2005 10:43:35 +0100
At 13:51 -0400 28/6/05, Chaskiel Grundman wrote:
should Finder/Dock/ATSServer be able to cope with this? In
particular, the lack of VOL_CAP_FMT_PERSISTENTOBJECTIDS,
VOL_CAP_INT_SEARCHFS, and VOL_CAP_INT_ATTRLIST
I would expect so. Mac OS X is certified to boot and root from UFS,
which has similar limitations. Also, folks at Apple use NFS home
directories day-to-day, and NFS has similar limitations. So,
software like Finder and Dock should work just fine on a file system
with standard Posix semantics.
I recently got my VFS (openafs) to the point where it more or less
works from the command line.
In order to stress it some (and because it's the primary application
that certain users will be useing it for), I attempted to set up an
account whose $HOME/Library was stored in the remote file-system. I
did this by
1) creating a new account
2) copying Library into the remote filesystem with rsync -a
3) replacing Library with a symbolic link into the remote filesystem.
Your test exercises weird code paths (see below). I'd recommend that
you copy the entire home directory, not just the ~/Library folder, to
your file system.
[The reason for that recommendation is that symlinks are represented
as synthetic aliases to programs that use the [Carbon] File Manager.
The following Q&A explains what a synthetic alias is.
<http://developer.apple.com/qa/qa2004/qa1351.html>
It's possible that some software is failing when it encounters a
synthetic alias in a place that's not expected.]
When I log in with the test account, the finder does not come up,
the searchlight icon appears in the upper right corner, and the
ATSServer seems to be spinning doing nothing (ATSServer is in R
state, and fs_usage shows no ATSServer activity after it
getdirentries the (empty) ~/Library/Fonts directory). killing
ATSServer causes it to respawn and break the same way.
These effects are remarkably like this user's report,:
<http://listserver.themacintoshguy.com/pipermail/X4U/2005-May/005982.html>
That's mighty weird. If it is a font cache problem, you can blow
away all caches on your system by nuking the contents of
~/Library/Caches, /Library/Caches, and /System/Library/Caches. As
the stuff contained therein is just a cache, the system should boot
just fine without it. But, please, only do this on a victim machine
(or a victim partition, if you only have one machine).
Debugging this sort of problem is hard. My experience is they are
related to how the File Manager uses the BSD file system APIs. The
File Manager stresses these APIs to the max, and some slight slip up
in your VFS's support can cause very hard-to-debug problems. Those
cases that I've found, I've documented in Q&As on our web site.
However, I'm sure there are still many others yet to be found.
<http://developer.apple.com/technicalqas/Darwin/idxFileManagement-date.html>
<http://developer.apple.com/technicalqas/Darwin/idxKernel-date.html>
You might also want to look at the File Manager section of Technote
2124 "Mac OS X Debugging Magic", which has some useful tips.
<http://developer.apple.com/technotes/tn2004/tn2124.html#SECCSFM>
Specifically, if you can find a way to enable the _debug libraries,
you'll get useful File Manager info from fs_usage.
If ATS is wedged, not much on the system is going to work. What does
a "sample" log of ATS look like?
Have you tested your mmap code path? This is something that VFS
developers often get wrong, and the system uses mmap a lot.
* * *
The best way to get to the bottom of problems like this is to open a
DTS incident. That will allow me to provide you with full time help.
If that's not possible, I can continue to help out on this list, but
supporting mailing lists isn't my primary focus.
<http://developer.apple.com/technicalsupport/index.html>
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden