On 10Jul2008 13:20, Manuel Vazquez Acosta <mva.led@gmail. comwrote:
| Cameron Simpson wrote:
| On 09Jul2008 15:54, Ethan Furman <ethan@stonelea f.uswrote:
| >The solution my team has used is to monitor the file size. If the file
| >has stopped growing for x amount of time (we use 45 seconds) the file is
| >done copying. Not elegant, but it works.
| >
| If you know that files appear in sequence (a single serial upload
| process, not multiple uploaders) you can augument this with a check
| that an additional file has started to upload, ergo the current file
| has finished. Of course, only you can decide if this might be relied upon.
|
| Hum, what about the last file in the sequence?
| I think polling file's size maybe a good indicator, as Ethan proposed.
Hence the word "augument". It may let you short circuit the time delay, if a
new file appears. Obviously it's not enough on its own.
--
Cameron Simpson <cs@zip.com.auD oD#743
| Cameron Simpson wrote:
| On 09Jul2008 15:54, Ethan Furman <ethan@stonelea f.uswrote:
| >The solution my team has used is to monitor the file size. If the file
| >has stopped growing for x amount of time (we use 45 seconds) the file is
| >done copying. Not elegant, but it works.
| >
| If you know that files appear in sequence (a single serial upload
| process, not multiple uploaders) you can augument this with a check
| that an additional file has started to upload, ergo the current file
| has finished. Of course, only you can decide if this might be relied upon.
|
| Hum, what about the last file in the sequence?
| I think polling file's size maybe a good indicator, as Ethan proposed.
Hence the word "augument". It may let you short circuit the time delay, if a
new file appears. Obviously it's not enough on its own.
--
Cameron Simpson <cs@zip.com.auD oD#743