site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Apr 9, 2007, at 4:57 PM, Nathaniel Gray wrote: I'm attaching sample code for anybody else who's trying to do this. Thanks again, -n8 --

...

...

-- Nathaniel Gray -- Caltech Computer Science ------> -- Mojave Project -- http://mojave.cs.caltech.edu -->

Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com On Apr 10, 2007, at 9:17 AM, Brian Bergstrand wrote: On Apr 9, 2007, at 11:51 PM, Nathaniel Gray wrote: On Apr 9, 2007, at 6:04 PM, Don Brady wrote: Is there any non-hackish way to detect the case-sensitivity of a filesystem, like a system call? statvfs doesn't appear to do it and statfs doesn't help either (case-sensitive and case- insensitive hfs+ have the same f_type and f_fstypename). Or is there no avoiding the "create foo, open Foo" hack? You can use pathconf(2) with the _PC_CASE_SENSITIVE selector. Note an EINVAL result for this selector generally implies case- sensitive. This works nicely for hfs+ in the case-sensitive and insensitive variants. Unfortunately it looks like EINVAL is returned by smbfs and fat32, which are both case-insensitive, and ufs, which is case- sensitive. So I guess this test is only reliable when EINVAL is not returned (probably just for hfs-family filesystems). Any other suggestions? You can get this info via the getattrlist() syscall (std disclaimer concerning code written in Mail applies): Thanks! This works really well AFAICT. I haven't tested on nfs or smbfs yet but it worked on ufs, fat32, hfs+, hfs+ case-sensitive, and afp. fscaps.c