DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12632>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12632 [PATCH] New <lsync> to synchronize a local directory from one or more <fileset>s ------- Additional Comments From [EMAIL PROTECTED] 2003-01-20 18:46 ------- Another issue that I ran into using the synchronize task is a problem with the copy task when it interacts with a samba mounted file system from linux/unix machine while the ant task is running on a windows machine. I had 3 different files that I created on the ntfs drive (all done from a W2K machine). I then copied the three files to the samba share mounted drive. Here are the last 5 digits of the time stamps that the java vm reports. I don't understand its behavior... As some round down, and some up. File a File b File c Local NTFS 35062 87359 18093 Mounted via samba 36000 88000 18000 As you can imagnine, this leads to a lot of unnecessary file copying by the synchronize task, as file c would have been recopied, even though it doesn't need to be. To fix this, I added a dateSlop feature to the synchronize, copy, and sourceFileScanner tasks/routines, so that by passing in a true for dateSlop, it would only copy files that are more than 1 second apart from each other in their time stamps. I dont expect that my way of fixing this would be allowed by the maintainers of ant (its really a hack) but this bug also makes synchronize worthless between ntfs and samba shares unless it is fixed. I dont know a better way to fix it. Suggestions? I hope that a fix of some sort for this bug is thought about and implemented at the same time that the synchronize task is added. I'm going to file it as a bug on the copy task. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
