X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; q=dns; s=default; b=d24zFStBgsdh6lKTQWol3+xQsimrn9kDipA0twiRo2M nyUWwiDP8VcRHcWQW6ZGiwza1G9I/NReMBjST2rcrbhaYO9E/JKsB5HeezYQY7hy 0Jtw+nbYIOc3a/GzObQc/aUV7xs2snR9lbtLEbXnTwFZr96i7fOI/bbc39FSK6/0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; s=default; bh=qkQ4CTX2pYnkU27nA6PXT8HjSRs=; b=XKO51ayiOGN1s97u0 MC/AUV3DGmss4Wk+6GkGY6OYrggiX4T2feXkxSPglfJrlBhB+WpyV1PU61Y/M5cD HVaO1WVb1HPjenivHDzSOxcFjeE2uAyY5mi27tt48Qf1SP4/uy9SqIb6OYWYfXBz MIBWeIg6vd4KKuodE3/ka5Dw5k= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,LOTS_OF_MONEY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=binaryauto, system32, System32, binary,auto X-HELO: Ishtar.sc.tlinx.org Message-ID: <58C0D744.2030005@tlinx.org> Date: Wed, 08 Mar 2017 20:17:08 -0800 From: "L. A. Walsh" User-Agent: Thunderbird MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount References: <58A4741E DOT 5020408 AT gmail DOT com> <20170216092611 DOT GE3889 AT calimero DOT vinschen DOT de> <58B0AA58 DOT 30504 AT tlinx DOT org> <20170228214321 DOT GB13542 AT calimero DOT vinschen DOT de> In-Reply-To: <20170228214321.GB13542@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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---+ 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