Re: |IO_REPARSE_TAG_MOUNTPOINT| (Junctions) not working for remote filesystems in Cygwin ?
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.
--
With best regards,
Andrey Repin
Thursday, February 6, 2025 12:44:40
Sorry for my terrible english...
--
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
Re: |IO_REPARSE_TAG_MOUNTPOINT| (Junctions) not working for remote filesystems in Cygwin ?
On Wed, 5 Feb 2025 at 16:56, Corinna Vinschen via Cygwin wrote: > > 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? Another issue: Any new feature in ms-nfs41-client must be backwards-compatible to Cygwin 3.3 32bit, to support Windows 10/32bit, unless someone ports Cygwin 3.6 to 32bit. Ced -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur -- 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
Re: |IO_REPARSE_TAG_MOUNTPOINT| (Junctions) not working for remote filesystems in Cygwin ?
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
building util-linux-2.40.2
We were attempting to build util-linux 2.40.2 for MSYS2, based on the source package of util-linux-2.40.2-2 from Cygwin [1]. We were scratching our heads as to why it wasn't building tasksel for us, when it did in your package. I evenutally saw in the cygport that it tests for sys/syscall.h and warns if it is not present. I could not find a package that provides this header. Can you explain where it comes from, so that we can also build util-linux? (For now, I added a couple extra patches to configure.ac to make it look for functions instead of syscall numbers [2]) 1: https://github.com/msys2/MSYS2-packages/pull/5194 2: https://github.com/msys2/MSYS2-packages/compare/bbc219480a47d1f0ab87b99302627815390f4ee1..e00b44ad67481a8ad1c490d2b5475d3500dac436 -- 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
exposing Windows mountpoints in Cygwin
Now that my patch to escape characters in /proc/mounts has been applied, I'll get back to what I was thinking about back in June. I would like to have a way to list Windows volume roots in Cygwin, and it seems to make sense to me to expose them via getmntent, /proc/mounts, etc. The way I see this working is probably to replace the available_drives mechanism for enumerating mounts in favor of using FindFirst/NextVolumeW and GetVolumePathNamesForVolumeNameW to enumerate cygdrive mount points. Before I expend any effort actually trying to do this, I wanted to ask if this is desirable/acceptable to do, or if there's some "institutional knowledge" as to why that won't actually work. -- 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
Re: building util-linux-2.40.2
Hi Jeremy,
On 2/6/2025 1:22 PM, Jeremy Drake via Cygwin wrote:
We were attempting to build util-linux 2.40.2 for MSYS2, based on the
source package of util-linux-2.40.2-2 from Cygwin [1]. We were scratching
our heads as to why it wasn't building tasksel for us, when it did in your
package. I evenutally saw in the cygport that it tests for sys/syscall.h
and warns if it is not present. I could not find a package that provides
this header. Can you explain where it comes from, so that we can also
build util-linux? (For now, I added a couple extra patches to
configure.ac to make it look for functions instead of syscall numbers [2])
1: https://github.com/msys2/MSYS2-packages/pull/5194
2:
https://github.com/msys2/MSYS2-packages/compare/bbc219480a47d1f0ab87b99302627815390f4ee1..e00b44ad67481a8ad1c490d2b5475d3500dac436
Apologies for the inconvenience. It's an unsettled matter if/whether
Cygwin should supply a sys/syscall.h. I cobbled together something to
allow the util-linux, and something else maybe FUSE-related, to complete
build without angst.
The following script creates on stdout something that works. Direct
stdout to /usr/include/sys/syscall.h if you dare ;-).
HTH,
..mark
---
#!/bin/sh
#
# gen-syscall-h.sh
# Generates #defines for a plausible Cygwin on stdout
# 2023/12/30 Original version by Mark A. Geisert
#
# This currently works by creating a list of all symbols exported
# by libcygwin.a and subtracting out the symbols also exported
# by libm.a. After that, a symbol is kept only if it starts with
# a lowercase letter and does not start with "cygwin_" or "main".
#
TMPF=/tmp/.$$.
trap 'rm -f $TMPF' EXIT
nm /usr/lib/libm.a | awk '/ T [a-z]/{print $3}' | sort > $TMPF
nm /usr/lib/libcygwin.a | awk '/ T [a-z]/ {print $3}' | \
grep -vE '^cygwin_|^main' | sort | \
diff --suppress-common-lines -y - $TMPF | \
awk '/^[a-z]/ {printf "#define SYS_%s %d\n", $1, ++RECNO}'
exit $?
--
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
