Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 Date: Thu, 16 Jan 2003 16:54:51 +0100 From: Thomas Baker To: "Larry Hall (RFK Partners, Inc)" Cc: cygwin AT cygwin DOT com Subject: Re: Losing data with routine cp and mv -- "cannot create hard link" Message-ID: <20030116155451.GB1576@LEPIDUS> Mail-Followup-To: Thomas Baker , "Larry Hall (RFK Partners, Inc)" , cygwin AT cygwin DOT com References: <20030112191731 DOT GA1336 AT LEPIDUS> <20030112191731 DOT GA1336 AT LEPIDUS> <4 DOT 3 DOT 1 DOT 2 DOT 20030116094419 DOT 02436b58 AT pop DOT rcn DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.1.2.20030116094419.02436b58@pop.rcn.com> User-Agent: Mutt/1.4i Simply knowing that this is not a frequently reported problem is helpful. I'm inclined to suspect now that Bjoern (previous post) is on the right track by looking at the timing of the deleting and creating that goes on under Win2000 (in this case) in order to "mv" something. Many thanks, Tom Baker On Thu, Jan 16, 2003 at 09:55:01AM -0500, Larry Hall (RFK Partners, Inc) wrote: > At 04:55 AM 1/16/2003, Thomas Baker wrote: > >In the absence of responses to my earlier note (below), and > >having made a second fruitless search of FAQs and archives, > >I'd like to make a second and final attempt with a simpler > >question: > > > > 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? > > > >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 you're looking for some 'official' validation of what you see, > I'm not sure that you'll find it here. It's not that we wouldn't like > to give it (or even refute your findings ;-) ). It's just that I don't > believe anyone has done as much analysis of this issue as you have. > Certainly, the values you report (89000 files occupying 1.4GB of space) are > not, in and of themselves, an obvious red-flag. If you'd like to get a > better handle on the situation (and help the list understand your problem as > well), it would be worthwhile to run strace on this process and look > for any suspect results. Be warned. This will generate a huge file > with lots of output, most of which is not going to indicate any problems. > However, if you can help isolate a problem area, it may be easier for > someone here to diagnose the problem and offer a fix... or at least an > explanation. > > Sorry I don't have the magic bullet for you. -- Dr. Thomas Baker Thomas DOT Baker AT bi DOT fhg DOT de Institutszentrum Schloss Birlinghoven mobile +49-171-408-5784 Fraunhofer-Gesellschaft work +49-30-8109-9027 53754 Sankt Augustin, Germany fax +49-2241-144-2352 -- 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/