swiftdirectorymetadatansfilewrapper

Distinguish between a NSFileWrapper and a directory?

I want to make my app filesystem keep metadata about each file in it but also support directory creation on the user side. I've looked at NSFileWrapper but it appears it saves files with metadata as directories. This makes sense, however now how do I differentiate between actual directories and NSFileWrapper directories? Or should I instead be keeping track of metadata with a hidden plist file in each directory? Thanks in advance for any help!

Solution

  • You can use setxattr to store extra key/value pairs of metadata on files. Mattt Thompson has written an excellent in-depth article on NSHipster.

    Here is the example from the article, showing how to set an attribute value:

    #include <sys/xattr.h>

    const char *filePath = [fileURL fileSystemRepresentation];
const char *name = "com.Example.Etag";
const char *value = [[response allHeaderFields][@"Etag"] UTF8String];
int result = setxattr(filePath, name, value, strlen(value), 0, 0);

    setxattr works on Mac filesystems which support extended metadata attributes. On OS X and iOS this is supported by HFS+, where the metadata is stored in the resource fork with a maximum size limited of 128KB.

    You can use listxattr to retrieve available tags. Use getxattr to retrieve the value for a specific tag.

    One example of an application which uses this is TextMate, which stores state information such as current caret position, bookmarks, and line folding.

    It is important to note that the metadata is volatile and should not be relied on to retain critical information.

    1. Metadata may be moved/changed/stripped for various reasons, such as being stored on a filesystem which does not support extended metadata (e.g. FAT32), or by being altered accidentally or intentionally by compression, networking, or other file handling software.
    2. The metadata is a shared namespace, which makes it great for interoperability with other applications, but is also vulnerable to interference. To avoid name collisions, key names should be prefixed with a unique identifier (i.e. a domain name).

    Additional references: