Re: Slow manipulation of network-shared files

[Chap Harrison <clh at pobox dot com>]

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