Reini Urban wrote: > > 5s looks more like a race. But I have no idea what could cause the race. > Could be that Java is still holding the handle until the gc frees it. > Interesting thought. I just tried a one-second delay before my first attempt to move the file after having seen the log message indicating the file had been closed. This was to lessen the likelihood that I would be in a race with file closing. It made no appreciable difference: for most files, I succeed in moving them on the first try; for maybe 10% I succeed in moving them after between 2 and 5 tries (at one-second intervals); for maybe 10% of them I fail at moving them but then fall back and successfully copy them instead; and for 3% of them, even the copy fails.
(Using 'copy' makes me nervous - if the problem is that the file is not completely & totally "closed", what if the final buffers of output haven't yet been flushed?) Your idea about Java holding the handle until gc runs sounds very plausible. Lastly, although I'm not sure I've eliminated all other variables, it appears that the problem is considerably worse in Cygwin 1.7 than in Cygwin 1.5. In 1.5, I succeed in moving the file on the first try about 95% of the time. Well, (he said, trying to be philosophical about it), in a way this whole effort is about racing with the Java app to scoop some output files away to safety before it circles around and clobbers them, so it's not surprising that it's less than 100% reliable. I'd welcome any ideas on improving my odds, however! :-) -- View this message in context: http://old.nabble.com/Slow-manipulation-of-network-shared-files-tp27474697p27481771.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
