przemoc
commented
9 years ago If we can relatively easy support previously unsupported FreeBSD, then we should surely do it. I'll make proper enhancement entry later. I had a quick glance at your work and while I applaud your effort put in FreeBSD-port branch, it will need some further work and reorganization.
- If you write some code, then you should use copyright line with your own name. :)
- Makefile will be changed by me later, so there will be no need to play with it (beside adding new source files, of course).
- I think I'll merge impro/switch-xattr-header as is (or almost as is), so your changes should be put on top of that branch.
- Instead of introducing
canonical_path_get(), please simply replacecanonicalize_file_name()calls with properrealpath()calls - removing non-portable GNUisms is always nice. Do it in separate commit, preferably in separate branch, e.g.impro/realpath-for-canonicalize, followed by pull request from that branch. Your actual FreeBSD-port should be branched on top of this improvement. - Mind that after above fix the abstraction will be no longer a general one, but xattr-related only, so we should name it appropriately. I suggest simple
xattrs.{h,c}with METASTORE_XATTRS_H as include guard define. - Spare us from
#ifunreadability hell. Createxattrs-linux.candxattrs-freebsd.c, and use preprocessor only once inxattrs.cto conditionally include one or the other if proper preprocessor defines are present. - Linux has four namespaces (user, trusted, security and system) and they're denoted in xattr key as prefix with dot. FreeBSD works on namespace at "binary" level with two namespaces (EXTATTR_NAMESPACE_USER, EXTATTR_NAMESPACE_SYSTEM), so we should map them to metastore file with prefixes like in Linux case (user and system only) and use prefix to properly restore them later (ditching the prefix when saving the key).
- Do not limit xattrs to user ones only on FreeBSD.
- I've seen some FIXMEs, but already forgot what they were and I haven't thought about them. Fix them if you're able to or we'll think about them on second iteration.
When you rebake your FreeBSD-port branch (I would rename it to enhan/freebsd-support), then please send me a pull request and we'll dwelve on it further in that PR and I'll close this issue then.
kmdawson
In investigation the generality of the currently suggested fix to fix to Issue #21, I discovered that it would be pretty straight-forward to port it to FreeBSD. That might be a nice enhancement.