git/fsmonitor-path-utils.h

61 lines
1.4 KiB
C
Raw Normal View History

#ifndef FSM_PATH_UTILS_H
#define FSM_PATH_UTILS_H
fsmonitor: deal with synthetic firmlinks on macOS Starting with macOS 10.15 (Catalina), Apple introduced a new feature called 'firmlinks' in order to separate the boot volume into two volumes, one read-only and one writable but still present them to the user as a single volume. Along with this change, Apple removed the ability to create symlinks in the root directory and replaced them with 'synthetic firmlinks'. See 'man synthetic.conf' When FSEevents reports the path of changed files, if the path involves a synthetic firmlink, the path is reported from the point of the synthetic firmlink and not the real path. For example: Real path: /System/Volumes/Data/network/working/directory/foo.txt Synthetic firmlink: /network -> /System/Volumes/Data/network FSEvents path: /network/working/directory/foo.txt This causes the FSEvents path to not match against the worktree directory. There are several ways in which synthetic firmlinks can be created: they can be defined in /etc/synthetic.conf, the automounter can create them, and there may be other means. Simply reading /etc/synthetic.conf is insufficient. No matter what process creates synthetic firmlinks, they all get created in the root directory. Therefore, in order to deal with synthetic firmlinks, the root directory is scanned and the first possible synthetic firmink that, when resolved, is a prefix of the worktree is used to map FSEvents paths to worktree paths. Signed-off-by: Eric DeCosta <edecosta@mathworks.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-05 01:32:29 +08:00
#include "strbuf.h"
struct alias_info
{
struct strbuf alias;
struct strbuf points_to;
};
struct fs_info {
int is_remote;
char *typename;
};
/*
fsmonitor: deal with synthetic firmlinks on macOS Starting with macOS 10.15 (Catalina), Apple introduced a new feature called 'firmlinks' in order to separate the boot volume into two volumes, one read-only and one writable but still present them to the user as a single volume. Along with this change, Apple removed the ability to create symlinks in the root directory and replaced them with 'synthetic firmlinks'. See 'man synthetic.conf' When FSEevents reports the path of changed files, if the path involves a synthetic firmlink, the path is reported from the point of the synthetic firmlink and not the real path. For example: Real path: /System/Volumes/Data/network/working/directory/foo.txt Synthetic firmlink: /network -> /System/Volumes/Data/network FSEvents path: /network/working/directory/foo.txt This causes the FSEvents path to not match against the worktree directory. There are several ways in which synthetic firmlinks can be created: they can be defined in /etc/synthetic.conf, the automounter can create them, and there may be other means. Simply reading /etc/synthetic.conf is insufficient. No matter what process creates synthetic firmlinks, they all get created in the root directory. Therefore, in order to deal with synthetic firmlinks, the root directory is scanned and the first possible synthetic firmink that, when resolved, is a prefix of the worktree is used to map FSEvents paths to worktree paths. Signed-off-by: Eric DeCosta <edecosta@mathworks.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-05 01:32:29 +08:00
* Get some basic filesystem information for the given path
*
* The caller owns the storage that is occupied by fs_info and
* is responsible for releasing it.
*
* Returns -1 on error, zero otherwise.
*/
int fsmonitor__get_fs_info(const char *path, struct fs_info *fs_info);
/*
* Determines if the filesystem that path resides on is remote.
*
* Returns -1 on error, 0 if not remote, 1 if remote.
*/
int fsmonitor__is_fs_remote(const char *path);
fsmonitor: deal with synthetic firmlinks on macOS Starting with macOS 10.15 (Catalina), Apple introduced a new feature called 'firmlinks' in order to separate the boot volume into two volumes, one read-only and one writable but still present them to the user as a single volume. Along with this change, Apple removed the ability to create symlinks in the root directory and replaced them with 'synthetic firmlinks'. See 'man synthetic.conf' When FSEevents reports the path of changed files, if the path involves a synthetic firmlink, the path is reported from the point of the synthetic firmlink and not the real path. For example: Real path: /System/Volumes/Data/network/working/directory/foo.txt Synthetic firmlink: /network -> /System/Volumes/Data/network FSEvents path: /network/working/directory/foo.txt This causes the FSEvents path to not match against the worktree directory. There are several ways in which synthetic firmlinks can be created: they can be defined in /etc/synthetic.conf, the automounter can create them, and there may be other means. Simply reading /etc/synthetic.conf is insufficient. No matter what process creates synthetic firmlinks, they all get created in the root directory. Therefore, in order to deal with synthetic firmlinks, the root directory is scanned and the first possible synthetic firmink that, when resolved, is a prefix of the worktree is used to map FSEvents paths to worktree paths. Signed-off-by: Eric DeCosta <edecosta@mathworks.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-05 01:32:29 +08:00
/*
* Get the alias in given path, if any.
*
* Sets alias to the first alias that matches any part of the path.
*
* If an alias is found, info.alias and info.points_to are set to the
* found mapping.
*
* Returns -1 on error, 0 otherwise.
*
* The caller owns the storage that is occupied by info.alias and
* info.points_to and is responsible for releasing it.
*/
int fsmonitor__get_alias(const char *path, struct alias_info *info);
/*
* Resolve the path against the given alias.
*
* Returns the resolved path if there is one, NULL otherwise.
*
* The caller owns the storage that the returned string occupies and
* is responsible for releasing it.
*/
char *fsmonitor__resolve_alias(const char *path,
const struct alias_info *info);
#endif