Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Thu, 16 Jan 2003 11:19:14 +0100 (MET)
From: Bjoern Kahl AG Resy <kahl AT informatik DOT uni-kl DOT de>
To: Thomas Baker <thomas DOT baker AT bi DOT fhg DOT de>
cc: cygwin AT cygwin DOT com
Subject: Re: Losing data with routine cp and mv -- "cannot create hard link"
In-Reply-To: <20030116095525.GA1856@LEPIDUS>
Message-ID: <Pine.GSO.4.44.0301161103210.1279-100000@domino.informatik.uni-kl.de>
References: <20030112191731 DOT GA1336 AT LEPIDUS> <20030116095525 DOT GA1856 AT LEPIDUS>
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


 Hallo!

 I do not know what is going on really, but I have seen something
 like that before.

On Thu, 16 Jan 2003, Thomas Baker wrote:

>    If cp and mv are not reliably copying all of the contents
>    of an (apparently) normal directory tree with 89,000 normal
>    data files, of 1.4 GB total size, using WIN2000 and NTFS,
>    is it most likely due to inherent size limits of cygwin?

  <wild guessing mode>

 There seems to be a random delay in the NT-Filesystem when renaming
 files. This can be easily triggert on smb-shares, but also on
 "normal" drives.

 If renaming (that is: moving around) files, there is a short,
 load-dependend delay between removing the old direktory entry and
 creating the new one. This can even be observed in the windows
 explorer, and I *think* that is not a slow-gui-issue, but the file
 is *really* *not* *there* form some time.

 </wild guessing mode>

 So dont think there is any thing cygwin can do.

> If the problems are due to inherent limits, then I can
> adjust by copying such big directories in smaller chunks,
> as I have already done successfully.  I just want to make
> sure that this is in fact the problem.

 If I move/copy some files over the net, I add sleep instructions
 ("for i in * ; do mv $i $i.bak ; sleep 1 ; sed <$i.bak >$i ... ; done")
 slow, but works. On *my* system, the magic number is around 50 files.
 Less than 50 files works without sleep, more files require the
 sleep. (Else I get a lot random "No such file xxx.bak".)


   Bjoern

-- 
+---------------------------------------------------------------------+
| Dipl.-Phys. Bjoern Kahl +++ AG Embedded Systems and Robotics (RESY) |
| Informatics Faculty +++ Building 48 +++ University of Kaiserslautern|
| phone: +49-631-205-2654 +++ www: http://resy.informatik.uni-kl.de   |
+---------------------------------------------------------------------+


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/