Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount
Greetings, L A Walsh!
> Andrey Repin wrote:
>> I would argue against all junctions being treated blindly.
>> The difference with bind mounts in Linux is that in Linux
>> you don't have the
>> information available within the filesystem itself, and have
>> no other option,
>> than to treat them as regular directories.
>> Only direct volume junctions cause an issue, and this is what
>> should be fixed,
>> if possible, not sidetracked with questionable workarounds.
>
> Could you describe the benefits of your proposed solution?
> You do know that MS originally called junctions "mountpoints",
> right? So why would cygwin treating them as such be a "questionable
> workaround"?
How they are called, and how they behave is a two different questions.
> How would you want to treat them?
Easy way: As symlinks, just like now, unless it's a volume mount point that
can't be normalized to a disk letter.
Preferred way: Fix volume mounts accessibility
\\?\{UUID} -> /dev/disk/by-uuid/UUID
--
With best regards,
Andrey Repin
Friday, March 10, 2017 16:10:57
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount
Corinna Vinschen wrote:
He's right. The mount point handling in Cygwin is based on the
in-memory mount table.
I'm not wanting a mount point fake. Just wanting it to look
like a normal dir just like the mountvol-junctions.
There's no reasonable way to fake some
reparse point to look like a mount point. We can either handle it
as normal dir, or as symlink. Handling it as normal dir is
problematic in terms of find/rsync
T All of the core utils are loop-protected in that respect.
same-dev file systems already exist on linux and cygwin.
File system loops are already present just using mountvol:
mountvol
...
\\?\Volume{578b2172-f917-11e4-b3d9-a0369f15ce28}\
C:\mountedVol\
/mountedVol> mkdir remounted
# note, next "2" lines are really 1 wrapped line:
/mountedVol> mountvol remounted
'\\?\Volume{578b2172-f917-11e4-b3d9-a0369f15ce28}\'
So the same volume is mounted at C:\mountedVol and at
C:\mountedVol\remounted.
etc, bacause the cross-device
check would fail and files are potentially visited multiple times.
That isn't what happens right now with mountvol:
find shows:
/> find mountedVol/ -type d
mountedVol/
mountedVol/$RECYCLE.BIN
mountedVol/$RECYCLE.BIN/S-1-5-21-1885695451-752926663-1105222378-1000
mountedVol/$RECYCLE.BIN/S-1-5-21-1885695451-752926663-1105222378-1025
mountedVol/$RECYCLE.BIN/S-1-5-21-1885695451-752926663-1105222378-500
mountedVol/$RECYCLE.BIN/S-1-5-21-3-7-3-5013
find: File system loop detected; ‘mountedVol/remounted’ is part of the
same file system loop as ‘mountedVol/’.
mountedVol/System Volume Information
I.e. 'find' (and other coreutils) detect the loop even though
they are the same file system.
Sure, you can find program(s) that are broken and don't detect
such loops, but at least the core utils do check -- and besides,
no one HAS to create junctions -- they can use symlinks as they do
today and no risk of such problems.
But treating linkd-junctions the same as mountvol-junctions allows
those bind-style mounts that are supported on linux and Windows
to be supported on Cygwin.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount
On Mar 9 07:48, L A Walsh wrote: > Andrey Repin wrote: > > I would argue against all junctions being treated blindly. > > The difference with bind mounts in Linux is that in Linux you don't have > > the > > information available within the filesystem itself, and have no other > > option, > > than to treat them as regular directories. > > Only direct volume junctions cause an issue, and this is what should be > > fixed, > > if possible, not sidetracked with questionable workarounds. > > Could you describe the benefits of your proposed solution? > > You do know that MS originally called junctions "mountpoints", > right? So why would cygwin treating them as such be a "questionable > workaround"? He's right. The mount point handling in Cygwin is based on the in-memory mount table. There's no reasonable way to fake some reparse point to look like a mount point. We can either handle it as normal dir, or as symlink. Handling it as normal dir is problematic in terms of find/rsync etc, bacause the cross-device check would fail and files are potentially visited multiple times. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount
Andrey Repin wrote: I would argue against all junctions being treated blindly. The difference with bind mounts in Linux is that in Linux you don't have the information available within the filesystem itself, and have no other option, than to treat them as regular directories. Only direct volume junctions cause an issue, and this is what should be fixed, if possible, not sidetracked with questionable workarounds. Could you describe the benefits of your proposed solution? You do know that MS originally called junctions "mountpoints", right? So why would cygwin treating them as such be a "questionable workaround"? How would you want to treat them? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount
Greetings, L. A. Walsh!
> Didn't see a response to this, so reposting, as this
> would provide a needed vol and subdir mount facility as
> exists on linux...
> Especially, since there was a misunderstanding of what
> was needed or wanted w/regards to the JUNCTION file-system
> mounts in Windows. Didn't need mount table updated, just
> needed it to look like a normal mount (as 1 of the
> 2 junction usages already does). So it's just a matter of
> making the other junction type w/a path be treated as
> a normal dir instead of a symlink. As it is now, it's
> inconsistent with junctions created with mountvol being
> different from junctions created with linkd.
> Symlink(D)s would stay as they are now and provide the
> symlink functionality.
I would argue against all junctions being treated blindly.
The difference with bind mounts in Linux is that in Linux you don't have the
information available within the filesystem itself, and have no other option,
than to treat them as regular directories.
Only direct volume junctions cause an issue, and this is what should be fixed,
if possible, not sidetracked with questionable workarounds.
> Original note:
> Corinna Vinschen wrote:
>>
>>> They
>>> half-way work under Cygwin (junctions to volumes look like
>>> mounted file systems look under linux, but junctions to
>>> pathnames get converted by cygwin to symlinks -- losing
>>> information when such junctions are restored.
>>>
>>> Corinna -- could you _please_ re-look at supporting both
>>> types of junctions as mount points? Then Cygwin could have
>>> "mount-parity" with linux! ;-)
>>>
>>
>> That's not easily possible. Mount points in Cygwin are virtual entries
>> stored in the per-user session, in-memory mount table.
> ---
>Ahh.. you are making it more complicated than what I'm
> asking! (yey! this should be simpler)...
>If I have a junction to the root of another volume, in
> cygwin it looks like a normal directory:
> Using mountvol...
> C:\>mountvol mountedVol \\?\Volume{578b2172-f917-11e4-b3d9-a0369f15ce28}
> 03/02/2017 01:24 PM mountedVol
> [\??\Volume{578b2172-f917-11e4-b3d9-a0369f15ce28}\]
> 01/11/2017 04:17 PM var [C:\Windows\System32\cygwin\var]
> ### a junction is created ... under Cygwin.
> Note, BTW, that 'var' is also a JUNCTION (a MS-mount point).
> C:\>exit
> exit
/>> ll
> total 100672654
> drwxrwx---+ 10 Nov 20 2010 $RECYCLE.BIN/
> ...
> drwxrwx---+ 10 May 15 2015 mountedVol/
> lrwxrwxrwx 1 28 Jan 11 16:17 var ->
> /Windows/System32/cygwin/var/
/>> ls mountedVol
> $RECYCLE.BIN/ System Volume Information/
> ### mountedVol looks like a normal directory ^^^, but 'var' shows
> ### as a symlink. That's the problem I'm referring to. I'm saying
> ### JUNCTIONs (MS-mountpoints) should show up as the 'same' in
> ### Cygwin -- i.e. --
> ### But is not necessary that it be shown in Cygwin's "mount table":
/>> mount
> C:/bin on /usr/bin type ntfs (binary,auto)
> C:/lib on /usr/lib type ntfs (binary,auto)
> C: on / type ntfs (binary,auto)
> B: on /b type smbfs (binary,user,noumount,auto)
> ...
>
> It's the same on linux.
> linux> stat -c %D /var
> 822
> linux> sudo mount --rbind /var/rtmp /tmp
> linux> stat -c %D /tmp
> 822
>
> A mount from the same fs to another place on the same fs,
> looks like a normal directory (not a symlink).
> This is the behavior I would want for 'JUNCTION's under
> Cygwin.
> On Windows, mklink creates a 'SYMLINK' or 'SYMLINKD' when
> directories are linked. Those would stay as "Symlinks".
> --
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
With best regards,
Andrey Repin
Thursday, March 9, 2017 16:33:49
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount
Didn't see a response to this, so reposting, as this
would provide a needed vol and subdir mount facility as
exists on linux...
Especially, since there was a misunderstanding of what
was needed or wanted w/regards to the JUNCTION file-system
mounts in Windows. Didn't need mount table updated, just
needed it to look like a normal mount (as 1 of the
2 junction usages already does). So it's just a matter of
making the other junction type w/a path be treated as
a normal dir instead of a symlink. As it is now, it's
inconsistent with junctions created with mountvol being
different from junctions created with linkd.
Symlink(D)s would stay as they are now and provide the
symlink functionality.
Original note:
Corinna Vinschen wrote:
They
half-way work under Cygwin (junctions to volumes look like
mounted file systems look under linux, but junctions to
pathnames get converted by cygwin to symlinks -- losing
information when such junctions are restored.
Corinna -- could you _please_ re-look at supporting both
types of junctions as mount points? Then Cygwin could have
"mount-parity" with linux! ;-)
That's not easily possible. Mount points in Cygwin are virtual entries
stored in the per-user session, in-memory mount table.
---
Ahh.. you are making it more complicated than what I'm
asking! (yey! this should be simpler)...
If I have a junction to the root of another volume, in
cygwin it looks like a normal directory:
Using mountvol...
C:\>mountvol mountedVol \\?\Volume{578b2172-f917-11e4-b3d9-a0369f15ce28}
03/02/2017 01:24 PM mountedVol
[\??\Volume{578b2172-f917-11e4-b3d9-a0369f15ce28}\]
01/11/2017 04:17 PM var [C:\Windows\System32\cygwin\var]
### a junction is created ... under Cygwin.
Note, BTW, that 'var' is also a JUNCTION (a MS-mount point).
C:\>exit
exit
/> ll
total 100672654
drwxrwx---+ 10 Nov 20 2010 $RECYCLE.BIN/
...
drwxrwx---+ 10 May 15 2015 mountedVol/
lrwxrwxrwx 1 28 Jan 11 16:17 var ->
/Windows/System32/cygwin/var/
/> ls mountedVol
$RECYCLE.BIN/ System Volume Information/
### mountedVol looks like a normal directory ^^^, but 'var' shows
### as a symlink. That's the problem I'm referring to. I'm saying
### JUNCTIONs (MS-mountpoints) should show up as the 'same' in
### Cygwin -- i.e. --
### But is not necessary that it be shown in Cygwin's "mount table":
/> mount
C:/bin on /usr/bin type ntfs (binary,auto)
C:/lib on /usr/lib type ntfs (binary,auto)
C: on / type ntfs (binary,auto)
B: on /b type smbfs (binary,user,noumount,auto)
...
It's the same on linux.
linux> stat -c %D /var
822
linux> sudo mount --rbind /var/rtmp /tmp
linux> stat -c %D /tmp
822
A mount from the same fs to another place on the same fs,
looks like a normal directory (not a symlink).
This is the behavior I would want for 'JUNCTION's under
Cygwin.
On Windows, mklink creates a 'SYMLINK' or 'SYMLINKD' when
directories are linked. Those would stay as "Symlinks".
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
