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/