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:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; q=dns; s= default; b=j+CWvNaPVC7001BhdS8gPG6o8e1Av/R355UlS5u8n0gxA0Oi4PC6k sSlMm12vIjhWF7RNcBMtLcvjYALshsZKU963qRgjHMziG7coZl3WO8HU5D4LpmPE KYX/s1TRwifIjMKK+vk+uhnTMbi3DdUhIHn+KdgslLCokfZ3xi9e38= 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:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; s=default; bh=6HEYoYhX+6/Vvc80BYeSeC6aN88=; b=J8WAzfKb0hJnAbjrtKuEGRYU5wA5 VkDElFXslfkhqaQP/hFnox3X5rcJkBbUbDcG47PXK3NNngWTVaaXAZtlfpmRsX45 Ige0a74oYmm13h6mXdxEz831A72BqrxJrqQ5xI0UHJIbC7P2tLKpPkyMEGCBPVLg A1dc8pheMJsK0fs= 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 X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 Date: Tue, 28 May 2013 17:33:02 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: Shadowcopy volume block devices Message-ID: <20130528153302.GL5264@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20130528133514 DOT GJ5264 AT calimero DOT vinschen DOT de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) On May 28 18:53, Micky wrote: > >On Tue, May 28, 2013 at 6:35 PM, Corinna Vinschen wrote: > > If you knew that you could access > > HarddiskVolumeShadowCopy using the POSIX path > > why didn't you try to use the POSIX path as device name in a call to the > > POSIX tool dd, rather than translating it into a Win32 path? It's clearly > > marked as block device in the directory listing: > > Because if I do that, the dd goes into a loop dumping an endless amount of data. That's not what you wrote in your OP. You wrote "but it doesn't let you access the volumes as block devices", which is pretty misleading as far as bug reports go. The endless loop problem accessing the device via /proc/sys/... should be fixed in CVS now. > When I tried c:\cygwin\dd.exe directly at the CMD with "\\.\" win32 > path, I got correct size of dump so that's why I knew something is up > with the block devices presented inside Cygwin (at least for dd). This has nothing to do with dd. It just calls read(2) so the behaviour is the same with any other application. The difference is the handling of DOS paths vs. the /proc/sys paths in the Cygwin DLL, the latter of which had a bug. I created a new developer snapshot. Please give the 2012-05-28 Cygwin DLL from http://cygwin.com/snapshots/ a try. I also created a new 64 bit test release Cygwin package 1.7.19-8 with this patch included. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer 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