X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Wed, 26 May 2010 16:25:03 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: Cygwin 1.7: Accessing (local) junctions via SMB Message-ID: <20100526142503.GL10652@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 On May 18 09:11, Mario Küchler wrote: > Hi, > > there seems to be a change from 1.5 to 1.7 when processing junctions > (reparse points). This was already discussed here but I want to point to > an issue when accessing them via SMB. > > Both hosts have a local junction from d:\temp to c:\temp. > > SMB connection goes from host1 to host2 (identical account, using > admin shared like c$, d$) > > > Results on 1.5: > > user AT host1 ~ > $ ls -la //host2/d\$/temp > > => shows the content of c:\temp on host_2_ (as expected) > > > Results on 1.7: > user AT host1 ~ > $ ls -l //host2/d\$/temp > lrwxrwxrwx (...) //host2/d$/temp -> /cygdrive/c/temp > > => resolves the local junction of host_2_ but translates it to the > local junction of host_1_, losing the UNC part ("//host2/"). Right, that's a problem. > Shouldn't this be parsed to //host2/c\$/temp .... That's not possible since that breaks reparse points via SMB in another way. The drive letters in such a reparse point won't have a meaning at all, unless drive C: is shared as //host/c, drive D: as //host/d, etc. What you're proposing - to use the administrative shares - only works for administrators. > ... as with Cygwin 1.5? Actually Cygwin 1.5 didn't parse reparse points at all. It just used them as if they were files or directories. In contrast, the behaviour of Cygwin 1.7, which is to read the actual reparse point content and treat it as symlinks, does not make sense for remote reparse points, apparently. Only the remote system knows how to treat them correctly. So I just applied a patch to Cygwin. In future it will only try to handle reparse points as symlinks if they are on a local filesystem. That should fix the aforementioned problem but keep the current behavior for local reparse points. Thanks for the report, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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