Hanin, I just found the problem. My setting accidentally contains checkUpToDate="false". That's why it tries to copy the file every time. I will close down the issue.
Thanks, testn wrote: > > It actually happens with both sync="true" and sync="false". The files are > copied every time but the modified timestamp will be reset to the original > timestamp in .ivy folder. > > > > Xavier Hanin wrote: >> >> On 6/14/07, testn <[EMAIL PROTECTED]> wrote: >>> >>> >>> Hi Hanin, >>> >>> I'm pretty sure. I fired up filemon to check it. I use <ivy:retrieve >>> sync="true" /> and it seems to copy all the file everytime. >>> >>> 10:11:55 AM java.exe:6380 READ >>> C:\workspace\repo\.ivy\cache\org.springframework\spring-core\jars\spring- >>> core-2.0.3.jar >>> SUCCESS Offset: 163840 Length: 8192 >>> 10:11:55 AM java.exe:6380 WRITE >>> C:\workspace\mystuff\lib\spring-core-2.0.3.jar SUCCESS Offset: 163840 >>> Length: 8192 >>> >>> Does it have anything to do if I don't have md5 and sha1 files? >> >> >> No, it shouldn't. It seems to be a bug so. Which version of Ivy do you >> use? >> Could you open a JIRA issue? >> >> Xavier >> >> Thanks >>> >>> >>> >>> Xavier Hanin wrote: >>> > >>> > On 6/14/07, Gilles Scokart <[EMAIL PROTECTED]> wrote: >>> >> >>> >> > 2. The buffer in FileUtils.java is too small. It's set at 8192. It >>> >> seems >>> >> > to >>> >> > > be much better for me to set it much larger. This is due to the >>> fact >>> >> > that >>> >> > > it >>> >> > > needs to read and write simultaneously. The bigger the buffer is, >>> the >>> >> > > smaller number of time, HD header has to move. For me, 65536 >>> seems >>> to >>> >> > > perform much better but I haven't tried other numbers. >>> >> > >>> >> > >>> >> > I'd like to get more feedback on this. One use case is not the >>> other. >>> >> This >>> >> > size has been borrowed from Ant copy mechanism. Maybe what we could >>> do >>> >> is >>> >> > make this configurable, so that one could adapt to its needs. Or >>> try >>> to >>> >> > guess a good size depending on the size (when it's possible to get >>> an >>> >> idea >>> >> > of the size before copying). >>> >> > >>> >> > Xavier >>> >> > >>> >> >>> >> >>> >> Couldn't we use the nio for that? (See >>> >> http://www.javalobby.org/java/forums/t17036.html) >>> > >>> > >>> > According to comments 10 and 11 NIO have bad performance for large >>> files >>> > on >>> > linux, and input stream with byte buffer is pretty close to NIO for >>> small >>> > files (see comment 13 conclusion). So I'm not sure switching to NIO >>> would >>> > indeed help a lot. According to the tests in the thread you pointed >>> using >>> > a >>> > 64kB buffer seems to be a good choice (which confirms testn tests), >>> at >>> > least for large files. OTOH the last conclusion (comment 17) is >>> different. >>> > So I don't really know what to think about that. We should make some >>> tests >>> > on several platforms and jvms to draw conclusion ourself, but it takes >>> > time. >>> > >>> > >>> > Xavier >>> > >>> > Gilles >>> >> >>> >> >>> >> >>> >> >>> > >>> > >>> > -- >>> > Xavier Hanin - Independent Java Consultant >>> > Manage your dependencies with Ivy! >>> > http://incubator.apache.org/ivy/ >>> > >>> > >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/ivy%3Aretrieve-performance-tf3907253.html#a11121249 >>> Sent from the ivy-user mailing list archive at Nabble.com. >>> >>> >> >> >> -- >> Xavier Hanin - Independent Java Consultant >> Manage your dependencies with Ivy! >> http://incubator.apache.org/ivy/ >> >> > > -- View this message in context: http://www.nabble.com/ivy%3Aretrieve-performance-tf3907253.html#a11121635 Sent from the ivy-user mailing list archive at Nabble.com.
