site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com -- Terry _______________________________________________ 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... On Apr 23, 2009, at 4:32 AM, Steve Checkoway wrote: On Apr 23, 2009, at 4:18 AM, Terry Lambert wrote: If you absolutely have to go though /Volumes for some bizarre and unexplainable reason, then you will need to lstat the path, see that it's a symbolic link, and use readlink(2) to read the link target, then use the link target as the path instead, internally. Of course it might be a relative path, and it might have . or .. in it, and if so, you will have to start with the dirname(3) and recompite the path as an absolute path before calling getattrlist() to make sure it fits in PATH_MAX characters. Of course going that route you could need to write a lot of code to handle complicated paths, like subtracting a path component when you see ../, or simply dropping ".". realpath(3)? Seems easier than reinventing the wheel but harder than just using getmntinfo(3). I have a couple of philosophical problems with realpath(3), starting with some of the unnecessary work that it does for the immediate problem here, and the folding of multiple disjoint failures into a single set of error codes so that you can't tell where the failure actually happened. It would be better if he just went by mountpoint, in any case, unless he's really asking questions to get to the same question that Vishal Chauhan just asked, in which event he's looking in the wrong place to get complete information. This email sent to site_archiver@lists.apple.com