From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 074611F54E for ; Sun, 11 Sep 2022 01:03:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229727AbiIKBB4 (ORCPT ); Sat, 10 Sep 2022 21:01:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229510AbiIKBBy (ORCPT ); Sat, 10 Sep 2022 21:01:54 -0400 Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1FFFB48C93 for ; Sat, 10 Sep 2022 18:01:53 -0700 (PDT) Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-346cd4c3d7aso60630527b3.8 for ; Sat, 10 Sep 2022 18:01:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=9ZtE83y00QnuAPkmiU1GxY56nosq20jDjgF69dMLcdE=; b=gWtt1E71PjCL0l7Rd6wauBYn0wmgWQE5G6sq1XGOWhRus8uy9hDtZgIf3Ufdfrz3Q4 Eoo4Cf9vdVT6YBohlhc4cLMnTMnaWyJv1lNNglseUNwmFyfjHjpVLcBh/KA7fr2zuuXf zJdREs11TGTlJpsaZvr3KUqUblvxJx5erL9JL4Qv6uRILAIxNDZ3E9460OAbERCbV8bY 74vfacVbL5aYK8jDrcU+MhC0caJrsPY8e86/Ii9cppmpniEAnsBLCNxWebayVNygoKj/ +8LD+AicPrbwswdtzP6rCXbeAIZq/8Rl0/0hjQrVwShMHHgoatoQJ2kYBo/M8b2M5vig EnXw== X-Gm-Message-State: ACgBeo2SBEVCR5cNr6CGLpqGlPgxd42k10rXdzHSCHGRUkbmTsYv65y8 YO61MW/Izp96iasHJu7nBpPPTHjTF/Hcl0DrlII= X-Google-Smtp-Source: AA6agR7RkgY1XXiswwGzuRsD4l0mh5NByVfDjzUS/a7mcVBmjb/NISj3qBm9DHEC2ePNdGUQAneXVwF0br1PfwOSA3M= X-Received: by 2002:a0d:c807:0:b0:336:cac2:59eb with SMTP id k7-20020a0dc807000000b00336cac259ebmr17405921ywd.70.1662858112201; Sat, 10 Sep 2022 18:01:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Sunshine Date: Sat, 10 Sep 2022 21:01:41 -0400 Message-ID: Subject: Re: [PATCH v5 4/4] fsmonitor: deal with synthetic firmlinks on macOS To: Eric DeCosta via GitGitGadget Cc: Git List , Jeff Hostetler , =?UTF-8?Q?Torsten_B=C3=B6gershausen?= , =?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= , Ramsay Jones , Johannes Schindelin , Eric DeCosta Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Sat, Sep 10, 2022 at 4:00 PM Eric DeCosta via GitGitGadget wrote: > 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 invloves > a synthetic firmlink, the path is reported from the point of the > synthetic firmlink and not the real path. For example: s/invloves/involves/ > 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 > --- > diff --git a/compat/fsmonitor/fsm-path-utils-darwin.c b/compat/fsmonitor/fsm-path-utils-darwin.c > @@ -38,3 +41,91 @@ int fsmonitor__is_fs_remote(const char *path) > +/* > + * Scan the root directory for synthetic firmlinks that when resolved > + * are a prefix of the path, stopping at the first one found. > + * > + * Some information about firmlinks and synthetic firmlinks: > + * https://eclecticlight.co/2020/01/23/catalina-boot-volumes/ > + * > + * macOS no longer allows symlinks in the root directory; any link found > + * there is therefore a synthetic firmlink. > + * > + * If this function gets called often, will want to cache all the firmlink > + * information, but for now there is only one caller of this function. > + * > + * If there is more than one alias for the path, that is another > + * matter altogteher. > + */ s/altogteher/altogether/ > diff --git a/fsmonitor-path-utils.h b/fsmonitor-path-utils.h > @@ -1,6 +1,14 @@ > +struct alias_info > +{ > + struct strbuf alias; > + struct strbuf points_to; > +}; > +/* > + * Get the alias in given path, if any. > + * > + * Sets alias to the first alias that matches any part of the path. > + * > + * Returns -1 on error, 0 otherwise. > + */ > +int fsmonitor__get_alias(const char *path, struct alias_info *info); I suppose it's somewhat clear here that the caller is responsible for releasing the strbufs in alias_info (though it's not clear why they need to be strbufs in the first place)... > +/* > + * Resolve the path against the given alias. > + * > + * Returns the resolved path if there is one, NULL otherwise. > + */ > +char *fsmonitor__resolve_alias(const char *path, > + const struct alias_info *info); But what about the return value from this function? It's `char*` which suggests a possible ownership transfer(?). Is the caller responsible for freeing it? If so, perhaps the documentation could state that.