Open Radar

 
Area:
Something not on this list

Summary:
APFS breaks code that works just fine with HFS+ volumes, even on latest 10.12.6 and 10.13b3.

When calling FSCatalogSearch and passing 0x200 (kFSCatInfoBackupDate) to its whichInfo parameter, the error code -50 (paramErr) is returned.

That's not good as it's unexpected:
1. Even on HFS Std vols, which have no backup time field, this works without error, and simply returns a "not available" value in the FSCatalogInfo field.
2. The constant "kFSCatInfoGettableInfo" includes this field, suggesting it should always work.
3. It breaks existing code.

Please consider this a regression and fix this in 10.13, at least. I can work around it by not requesting this info any more, but it's still not right that it breaks existing apps.

Steps to Reproduce:
Attached is an Xcode project to demonstrate the issue.

It's a cmdline tool, with the first arg being the search text (i.e. a partial file name to find), the second the path to the volume, such as "/Volumes/TestVol".

If you run it to search on a HFS+ volume, it'll work. Running on a APFS volume will lead to a paramErr.
If you remove the "kFSCatInfoBackupDate" bit from the code, it'll run without error on APFS.

Here's an example of using the cmd in Terminal on a HFS and a APFS volume:

$ ./catsearch /
Searching on '/'...
Result: 0

$ ./catsearch /Volumes/APFS1
Searching on '/Volumes/APFS1'...
Result: -50

Expected Results:
Requesting kFSCatInfoBackupDate should not stop with an error.

Observed Results:
Requesting kFSCatInfoBackupDate returns error code -50.

Version:
Same behavior on 10.12.6 and 10.13b3