Known issues that have could have only ugly work-arounds at best:

• The backslash is the ONLY reserved character in key/value names under regfs. Win32 doesn't handle many of NTFS's reserved characters very well.
  • Win32 converts any number of contiguous forward slashes into a single backslash during an open operation. Any key/value names that contain forward slashes will be listed but unopenable.
  • Wildcard characters ("*" and "!") and pipe characters (">", "<" and "|") in key or value names are often not handled correctly by Win32 programs.
• The registry provides no random access functions for values, so Regfs has to double-buffer an entire value for all read/write operations. This means that reading a single byte from the end of a 4MB file requires regfs to read the entire 4MB temporarily into kernel memory so it can copy the last byte into the user's buffer. This can be slow and puts an upper limit on the size of values. It is recommended that values do not exceed a few K in size (but still possible to exceed), same as Microsoft's own registry value recommendations. (Note that Regfs always deals with names in Unicode when accessing the registry)
• Every value in the registry has a number that declares the value's data type; for example, REG_SZ denotes a string and is number 1. This metadata is NOT a part of the value's name-- you cannot have two different values that differ only in type in the same key. Windows filesystem conventions store a file's type in the file's extension, but this idiom is not compatible with registry types because it DOES allow two files to exist that differ only in extension.
  Regfs treats a file's extension as a part of the file name and makes the value type available as an extended attribute. This is a clean solution, but has no application support.
• Because of the different naming rules and metadata that registry keys and values have, don't use standard file copy programs to copy keys or values.

The following standard filesystem functions are not implemented, but may be in a future version on a best-effort (i.e. not supported by direct registry access) basis.

• No range locking is performed. This matches the registry's own lack of locking. Lock functions claim to succeed but do nothing. Note that regfs does synchronize with itself during write operations.
• Change notifications are not supported. The registry does provide change notifications, but with far less detail about what changes actually occurred than a filesystem is required to.