* Cannot access volumes mounted with 'mklink /d' which point to a volume UUID @ 2017-02-15 15:30 Matt D. 2017-02-16 0:59 ` L. A. Walsh ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Matt D. @ 2017-02-15 15:30 UTC (permalink / raw) To: cygwin On Windows you can create symbolic links which point to volume UUIDs as a way of mounting and unmounting them without having to use the administrative disk management tools. For example, in cmd: mountvol ... \\?\Volume{079b79c9-0000-0000-0000-100000000000}\ C:\ ... mklink /d test \\?\Volume{079b79c9-0000-0000-0000-100000000000}\ ... dir test I call mounvol to get a list of volumes and create a symbolic link 'test' which points to the C:\ UUID. When I then 'dir test' it will list all files on that volume. If I try to access it through Cygwin Bash I get the following error: $ dir test/ dir: cannot access 'test/': No such file or directory This makes it difficult to work with unmounted volumes as it's not always possible to access the administrative disk management snap-in and the mountvol/mklink has always been my go-to for this type of functionality. It would be great if Cygwin would support it. Matt D. -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Cannot access volumes mounted with 'mklink /d' which point to a volume UUID 2017-02-15 15:30 Cannot access volumes mounted with 'mklink /d' which point to a volume UUID Matt D. @ 2017-02-16 0:59 ` L. A. Walsh 2017-02-16 9:26 ` Corinna Vinschen 2017-02-16 14:05 ` Cannot access volumes mounted with 'mklink /d' which point to a volume UUID Andrey Repin 2 siblings, 0 replies; 13+ messages in thread From: L. A. Walsh @ 2017-02-16 0:59 UTC (permalink / raw) To: cygwin Matt D. wrote: > On Windows you can create symbolic links which point to volume UUIDs > as a way of mounting and unmounting them without having to use the > administrative disk management tools. > > For example, in cmd: > > mountvol > ... > \\?\Volume{079b79c9-0000-0000-0000-100000000000}\ > C:\ > ... > mklink /d test \\?\Volume{079b79c9-0000-0000-0000-100000000000}\ --- mklink and mklink /d create SYMLINKs (and SYMLINKDs). To create MS mount points you need to create them as junctions (mklink /J) and I think that should work for what you are doing. Unfortunately, cygwin breaks MS-mounts by treating them as symlinks, so if you use standard *nix utils to copy that dir, it won't be read as a dir, but as a symlink, so when it's written to a destination, it seems like it would attempt to overwrite the directory with a symlink. I know it messes up being able to keep cygwin dirs on a separate disk unless you _only_ store 1 cygwin-dir/mount point. For example, if you have a cygwin on a "D" drive, you won't be able to use junctions to mount D:/usr on /usr and D:/bin on /bin without cygwin destroying the mountpoints when software is installed. Very unfortunate, since linux DOES have the dynamic-mount points with its 'bind' options. Somehow, having users be able to destroy mount-points doesn't seem that secure. -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Cannot access volumes mounted with 'mklink /d' which point to a volume UUID 2017-02-15 15:30 Cannot access volumes mounted with 'mklink /d' which point to a volume UUID Matt D. 2017-02-16 0:59 ` L. A. Walsh @ 2017-02-16 9:26 ` Corinna Vinschen 2017-02-24 21:49 ` L. A. Walsh 2017-02-16 14:05 ` Cannot access volumes mounted with 'mklink /d' which point to a volume UUID Andrey Repin 2 siblings, 1 reply; 13+ messages in thread From: Corinna Vinschen @ 2017-02-16 9:26 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1816 bytes --] On Feb 15 07:30, Matt D. wrote: > On Windows you can create symbolic links which point to volume UUIDs as a > way of mounting and unmounting them without having to use the administrative > disk management tools. > > For example, in cmd: > > mountvol > ... > \\?\Volume{079b79c9-0000-0000-0000-100000000000}\ > C:\ > ... > mklink /d test \\?\Volume{079b79c9-0000-0000-0000-100000000000}\ > ... > dir test > > I call mounvol to get a list of volumes and create a symbolic link 'test' > which points to the C:\ UUID. When I then 'dir test' it will list all files > on that volume. > > If I try to access it through Cygwin Bash I get the following error: > > $ dir test/ > dir: cannot access 'test/': No such file or directory > > This makes it difficult to work with unmounted volumes as it's not always > possible to access the administrative disk management snap-in and the > mountvol/mklink has always been my go-to for this type of functionality. It > would be great if Cygwin would support it. This type of directory symlink to a GUID volume path isn't supported at all yet in Cygwin. However, you can access the directory directly without having to go through MKLINK. In Cygwin: $ cd /proc/sys/GLOBAL\?\?/Volume{079b79c9-0000-0000-0000-100000000000}/ or $ ln -s \ /proc/sys/GLOBAL\?\?/Volume\{079b79c9-0000-0000-0000-100000000000}/ \ my_vol $ cd my_vol Note the trailing slash. Volume{079b79c9-0000-0000-0000-100000000000} without the slash is the block device. Volume{079b79c9-0000-0000-0000-100000000000}/ with trailing slash is the filesystem on the block device. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Cannot access volumes mounted with 'mklink /d' which point to a volume UUID 2017-02-16 9:26 ` Corinna Vinschen @ 2017-02-24 21:49 ` L. A. Walsh 2017-02-28 21:43 ` Corinna Vinschen 0 siblings, 1 reply; 13+ messages in thread From: L. A. Walsh @ 2017-02-24 21:49 UTC (permalink / raw) To: cygwin; +Cc: codespunk+cygwin Corinna Vinschen wrote: > This type of directory symlink to a GUID volume path isn't supported > at all yet in Cygwin. As I mentioned, symlinks don't support volume destinations under windows, but Junctions should be used instead. 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! ;-) Thanks! -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Cannot access volumes mounted with 'mklink /d' which point to a volume UUID 2017-02-24 21:49 ` L. A. Walsh @ 2017-02-28 21:43 ` Corinna Vinschen 2017-03-02 21:43 ` showing all JUNCTIONS as normal dirs as w/linux --bind (was Re: Cannot access volumes mounted with 'mklink...) L. A. Walsh 2017-03-09 4:17 ` Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount L. A. Walsh 0 siblings, 2 replies; 13+ messages in thread From: Corinna Vinschen @ 2017-02-28 21:43 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1348 bytes --] On Feb 24 13:49, L. A. Walsh wrote: > Corinna Vinschen wrote: > > This type of directory symlink to a GUID volume path isn't supported > > at all yet in Cygwin. > As I mentioned, symlinks don't support volume destinations > under windows, but Junctions should be used instead. 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. You can't easily fetch all dir junctions on a volume, and the mount table is also restricted in size. Volume junctions look like mount points because the device id changes below the reparse point, while they don't for dir junctions to the same volume. If you want them handled as mount points, add the path as a Cygwin mount point to /etc/fstab or /etc/fstab.d/$USER Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* showing all JUNCTIONS as normal dirs as w/linux --bind (was Re: Cannot access volumes mounted with 'mklink...) 2017-02-28 21:43 ` Corinna Vinschen @ 2017-03-02 21:43 ` L. A. Walsh 2017-03-09 4:17 ` Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount L. A. Walsh 1 sibling, 0 replies; 13+ messages in thread From: L. A. Walsh @ 2017-03-02 21:43 UTC (permalink / raw) To: cygwin 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 <JUNCTION> mountedVol [\??\Volume{578b2172-f917-11e4-b3d9-a0369f15ce28}\] 01/11/2017 04:17 PM <JUNCTION> 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---+ 1 0 Nov 20 2010 $RECYCLE.BIN/ ... drwxrwx---+ 1 0 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount 2017-02-28 21:43 ` Corinna Vinschen 2017-03-02 21:43 ` showing all JUNCTIONS as normal dirs as w/linux --bind (was Re: Cannot access volumes mounted with 'mklink...) L. A. Walsh @ 2017-03-09 4:17 ` L. A. Walsh 2017-03-09 13:50 ` Andrey Repin 1 sibling, 1 reply; 13+ messages in thread From: L. A. Walsh @ 2017-03-09 4:17 UTC (permalink / raw) To: cygwin 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 <JUNCTION> mountedVol [\??\Volume{578b2172-f917-11e4-b3d9-a0369f15ce28}\] 01/11/2017 04:17 PM <JUNCTION> 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---+ 1 0 Nov 20 2010 $RECYCLE.BIN/ ... drwxrwx---+ 1 0 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount 2017-03-09 4:17 ` Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount L. A. Walsh @ 2017-03-09 13:50 ` Andrey Repin 2017-03-09 15:48 ` L A Walsh 0 siblings, 1 reply; 13+ messages in thread From: Andrey Repin @ 2017-03-09 13:50 UTC (permalink / raw) To: L. A. Walsh, cygwin 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 <JUNCTION> mountedVol > [\??\Volume{578b2172-f917-11e4-b3d9-a0369f15ce28}\] > 01/11/2017 04:17 PM <JUNCTION> 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---+ 1 0 Nov 20 2010 $RECYCLE.BIN/ > ... > drwxrwx---+ 1 0 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount 2017-03-09 13:50 ` Andrey Repin @ 2017-03-09 15:48 ` L A Walsh 2017-03-09 16:41 ` Corinna Vinschen 2017-03-10 13:20 ` Andrey Repin 0 siblings, 2 replies; 13+ messages in thread From: L A Walsh @ 2017-03-09 15:48 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount 2017-03-09 15:48 ` L A Walsh @ 2017-03-09 16:41 ` Corinna Vinschen 2017-03-09 19:13 ` L A Walsh 2017-03-10 13:20 ` Andrey Repin 1 sibling, 1 reply; 13+ messages in thread From: Corinna Vinschen @ 2017-03-09 16:41 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1287 bytes --] 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount 2017-03-09 16:41 ` Corinna Vinschen @ 2017-03-09 19:13 ` L A Walsh 0 siblings, 0 replies; 13+ messages in thread From: L A Walsh @ 2017-03-09 19:13 UTC (permalink / raw) To: cygwin 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-33333-77777-33333-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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount 2017-03-09 15:48 ` L A Walsh 2017-03-09 16:41 ` Corinna Vinschen @ 2017-03-10 13:20 ` Andrey Repin 1 sibling, 0 replies; 13+ messages in thread From: Andrey Repin @ 2017-03-10 13:20 UTC (permalink / raw) To: L A Walsh, cygwin 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Cannot access volumes mounted with 'mklink /d' which point to a volume UUID 2017-02-15 15:30 Cannot access volumes mounted with 'mklink /d' which point to a volume UUID Matt D. 2017-02-16 0:59 ` L. A. Walsh 2017-02-16 9:26 ` Corinna Vinschen @ 2017-02-16 14:05 ` Andrey Repin 2 siblings, 0 replies; 13+ messages in thread From: Andrey Repin @ 2017-02-16 14:05 UTC (permalink / raw) To: Matt D., cygwin [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=utf-8, Size: 3655 bytes --] Greetings, Matt D.! > On Windows you can create symbolic links which point to volume UUIDs as > a way of mounting and unmounting them without having to use the > administrative disk management tools. > For example, in cmd: > mountvol > ... > \\?\Volume{079b79c9-0000-0000-0000-100000000000}\ > C:\ > ... > mklink /d test \\?\Volume{079b79c9-0000-0000-0000-100000000000}\ > ... > dir test > I call mounvol to get a list of volumes and create a symbolic link > 'test' which points to the C:\ UUID. When I then 'dir test' it will list > all files on that volume. > If I try to access it through Cygwin Bash I get the following error: > $ dir test/ > dir: cannot access 'test/': No such file or directory > This makes it difficult to work with unmounted volumes as it's not > always possible to access the administrative disk management snap-in and > the mountvol/mklink has always been my go-to for this type of > functionality. It would be great if Cygwin would support it. $ (mountvol; cmd /C dir /N) | iconv -f CP866; dir sd?1/ ... \\?\Volume{80006d80-c2bb-4297-93c1-2f6d1a2a8acb}\ C:\ C:\dev\sda1\ \\?\Volume{6833c423-2223-11e4-b07d-806e6f6e6963}\ *** ÐÐТ ТÐЧÐÐ ÐÐÐÐÐЮЧÐÐÐЯ *** \\?\Volume{9d412aba-0e54-4628-9c6b-b84fb18d062a}\ *** ÐÐТ ТÐЧÐÐ ÐÐÐÐÐЮЧÐÐÐЯ *** \\?\Volume{6833c424-2223-11e4-b07d-806e6f6e6963}\ *** ÐÐТ ТÐЧÐÐ ÐÐÐÐÐЮЧÐÐÐЯ *** \\?\Volume{51810762-adac-11e4-9801-902b3437d8e4}\ W:\ \\?\Volume{152b5e11-3180-11e4-9bb8-806e6f6e6963}\ R:\ ... 13.08.2016 23:13 <DIR> . 13.08.2016 23:13 <DIR> .. 21.08.2015 00:30 <JUNCTION> sda1 [\\?\Volume{80006d80-c2bb-4297-93c1-2f6d1a2a8acb}\] 31.08.2014 23:57 <JUNCTION> sdb1 [\\?\Volume{9d412aba-0e54-4628-9c6b-b84fb18d062a}\] 31.08.2014 23:55 <JUNCTION> sdc1 [\\?\Volume{6833c423-2223-11e4-b07d-806e6f6e6963}\] 31.08.2014 23:55 <JUNCTION> sdd1 [\\?\Volume{6833c424-2223-11e4-b07d-806e6f6e6963}\] 16.02.2017 13:43 <DIR> temp ... sda1/: $Recycle.Bin Documents\ and\ Settings hiberfil.sys Program\ Files Users arc DrWeb home Program\ Files\ (x86) usr Config.Msi DrWeb\ Quarantine os792636.bin ProgramData var cygwin ftn pagefile.sys Programs Windows dev Games PerfLogs System\ Volume\ Information sdb1/: $RECYCLE.BIN DirectoryHotlist.reg Program\ Files reg System\ Volume\ Information dev Fraps Programs reg~ url.nobrain sdc1/: $RECYCLE.BIN EDIUS-Data Profiles src usr 10-remote-vpn.conf eventcuts.zip Programs System\ Volume\ Information var CapCharges.jpg FCPF9C.html RECYCLER temp VirtualBox default.wjr ftn REINST Thumbs.db VirtualPad Disks Other Reserv Track12-2.wav xD-2010-07-23.rar sdd1/: $RECYCLE.BIN arc Games Scratch System\ Volume\ Information -- With best regards, Andrey Repin Thursday, February 16, 2017 16:55:19 Sorry for my terrible english...\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06GG\x03¢òö7wvâæ6öÒ÷\a&ö&ÆV×2æFÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06GG\x03¢òö7wvâæ6öÒöf\x17\x12ðФFö7VÖVçF\x17Föã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06GG\x03¢òö7wvâæ6öÒöFö72æFÖÀÐ¥Vç7V'67&&R\x06æfó¢\x02\x02\x02\x02\x02\x06GG\x03¢òö7wvâæ6öÒöÖÂò7Vç7V'67&&R×6×\x06ÆPÐ Ð ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-03-10 13:20 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-15 15:30 Cannot access volumes mounted with 'mklink /d' which point to a volume UUID Matt D. 2017-02-16 0:59 ` L. A. Walsh 2017-02-16 9:26 ` Corinna Vinschen 2017-02-24 21:49 ` L. A. Walsh 2017-02-28 21:43 ` Corinna Vinschen 2017-03-02 21:43 ` showing all JUNCTIONS as normal dirs as w/linux --bind (was Re: Cannot access volumes mounted with 'mklink...) L. A. Walsh 2017-03-09 4:17 ` Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount L. A. Walsh 2017-03-09 13:50 ` Andrey Repin 2017-03-09 15:48 ` L A Walsh 2017-03-09 16:41 ` Corinna Vinschen 2017-03-09 19:13 ` L A Walsh 2017-03-10 13:20 ` Andrey Repin 2017-02-16 14:05 ` Cannot access volumes mounted with 'mklink /d' which point to a volume UUID Andrey Repin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).