DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 516CP3RV2316691 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 516CP3RV2316691 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=cxXjw/tW X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5513A385841F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1738844701; bh=l/CjdVGGh0DzJ4RZ4cMXhEjYFdczUTpcAViqi1rtcEc=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=cxXjw/tWGBy7hW5L4RA+c0fxBx2VqHJtdlKMkT4W+sQzHCG9nTwrUOEWVyxmxQePA DD1t71ujDMQrmzwfsl7zSi3nBKaykBMFlc/dD4oy80KgBj/w5eLEPK4IzM9tWQMbMb Kpbc8NPlZn5DK+XreSRhZP/ZevLa6tEFjyDtzQ/Y= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B925E3858CD1 Date: Thu, 6 Feb 2025 13:24:37 +0100 To: cygwin AT cygwin DOT com Subject: Re: |IO_REPARSE_TAG_MOUNTPOINT| (Junctions) not working for remote filesystems in Cygwin ? Message-ID: Mail-Followup-To: cygwin AT cygwin DOT com References: <35e9e310-91d7-41e5-7e98-c1658030e912 AT jdrake DOT com> <1084215042 DOT 20250206124724 AT yandex DOT ru> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1084215042.20250206124724@yandex.ru> X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Corinna Vinschen via Cygwin Reply-To: cygwin AT cygwin DOT com Cc: Corinna Vinschen Content-Type: text/plain; charset="utf-8" Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 516CP3RV2316691 On Feb 6 12:47, Andrey Repin via Cygwin wrote: > Greetings, Corinna Vinschen via Cygwin! > > > On Feb 4 14:47, Jeremy Drake via Cygwin wrote: > >> On Tue, 4 Feb 2025, Roland Mainz via Cygwin wrote: > >> > >> > it seems that Cygwin does not support |IO_REPARSE_TAG_MOUNTPOINT| for > >> > "remote" filesystems: > >> > ---- snip ---- > >> > 2582 /* Don't handle junctions on remote filesystems as > >> > symlinks. This type > >> > 2583 of reparse point is handled transparently by the OS so that the > >> > 2584 target of the junction is the remote directory it is > >> > supposed to > >> > 2585 point to. If we handle it as symlink, it will be mistreated as > >> > 2586 pointing to a dir on the local system. */ > >> > > >> > The matching code in our filesystems seems to work in PowerShell and > >> > cmd.exe - so what context am I missing ? > >> > >> The comment seemed to explain it pretty well. Junctions are always > >> absolute. If it is absolute to a local path, that path is local to the > >> server, not the client. If Cygwin treated it as a symlink, it would see > >> the target as /cygdrive/c/whatever and would try to follow that to the > >> client-local directory. By *not* treating those as symlinks, it will > >> instead treat them as ordinary directories to be traversed, which will > >> allow the OS to handle them as normal. > > > Well explained. > > >> Perhaps it could be relaxed to allow remote junctions to be treated as > >> symlinks if their targets are UNC rather than local? Is that the case > >> your filesystems are exposing? > > > Just to be clear, there are two types. > > > The official volume mount points using the GUID-style volume names as > > introduced with the Vista volume manager shouldn't be touched at all for > > the reason stated above. > > > The junctions points are usually pointing to some local directory > > in the form \??\X:\... We can't use them for the same reason. > > > But if your NFS client would be so kind to convert them to the UNC > > type of path, i. e., \??\UNC\server\path, then we could test it in > > Cygwin and actually expose them as symlinks. > > > However, is it really worth the effort? > > > Right now, those remote reparse points of type > > IO_REPARSE_TAG_MOUNT_POINT are transparently handled by the OS, that's > > why there's no problem using them in PS or cmd. They are just passed > > through. > > > In Cygwin, symlinks of any type are handled as symlinks. That means, > > evaluating a path with a symlink requires to open the symlink and read > > the target path from it, then replace parts or all of the current path > > with the symlink content, to create a final POSIX/Win32 path pair from > > it. > > > So you have a (small) performance hit, for the not so obvious gain to > > see a remote junction as symlink in Cygwin. > > > I'm not judging here, I'm really asking for your opinion. > > To add another stone to the pile, > > $ fsutil behavior set symlinkEvaluation > > … > symlinkEvaluation {L2L|L2R|R2R|R2L}:{0|1} [...] > … > > Sample SymlinkEvaluation command: > "fsutil behavior set symlinkEvaluation L2L:1 L2R:0" > - Will enable local to local symbolic links and disable local to > remote symbolic links. It will not change the state of remote to > remote links or remote to local links. > - This operation takes effect immediately (no reboot required) > > The platform behavior could be different from user's expectations. And it is > not library's job to second-guess the OS behavior. Good point, but I don't think this affects IO_REPARSE_TAG_MOUNT_POINT reparse points. This should (afaik, grain of salt and all that) only affect reparse points of type IO_REPARSE_TAG_SYMLINK. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple