We are definitely continuing to pursue this and sorry that we don't have anything to report in the way of a fix.

In case you are curious, the code involved is the following:

.......
// Request lock on the given file with given fd.  Returns:
// 0 if we get lock
// PID (>0) if another process has lock
// -1 if error
//
int mylockf(int fd) {
    struct flock fl;
    fl.l_type=F_WRLCK;
    fl.l_whence=SEEK_SET;
    fl.l_start=0;
    fl.l_len=0;
    if (-1 != fcntl(fd, F_SETLK, &fl)) return 0;

    // if lock failed, find out why
    errno=0;
    fcntl(fd, F_GETLK, &fl);
    if (fl.l_pid>0) return fl.l_pid;
    return -1;
}

.....
   if ((pid=mylockf(fd))) {
    	  if ( pid == -1 ) {
        	log_messages.printf(MSG_CRITICAL,
            "handle_get_file_size(): [%s] error locking file: %s\n", file_name, strerror(errno)
        	);
    		}
        // file locked by another file_upload_handler: try again later
        //
        close(fd);
        log_messages.printf(MSG_CRITICAL,
            "handle_get_file_size(): [%s] returning error\n", file_name
        );
        if ( pid == -1 ) {
        	log_messages.printf(MSG_CRITICAL,
            "handle_get_file_size(): [%s] error locking file: %s\n", file_name, strerror(errno)
        	);
        	return return_error(ERR_TRANSIENT,
            	"[%s] error locking file", file_name
        	);
     		} else {
        	return return_error(ERR_TRANSIENT,
            	"[%s] locked by file_upload_handler PID=%d", file_name, pid
        	);
      	}
    } 
.....

I added some logging to get the value of errno after the fcntl(fd, F_SETLKW, &fl) call and it reported EAGAIN - "Resource temporarily unavailable"

We are trying to determine why some files are generating this message.

Apologies for the delays.

Is working- upload completed.

Otherwise I would have to copy it on CD and send it with snail-mail to Harvard.

Must have worked for me as well, that unit is no longer on my system. I assume it transferred automatically while I was away.

Edit: Found the result, it's uploaded and validated. I'd say we have a resolved.

It has been resolved for me as well. Should the thread be set to 'Resolved'?

It doesn't seem to work for me. I've got three or four machines that still have file transfers failing. It seems to upload some datasets properly; others it cannot seem to upload them. For instance, a computation that just finished transferred it's _4 file fine.

When it fails to upload, the log shows:
Fri 09 Jul 2010 08:50:20 AM PDT World Community Grid Started upload of E200101_172_A.19.C14H8N4S.75.set1d06_1_4
Fri 09 Jul 2010 08:50:26 AM PDT Project communication failed: attempting access to reference site
Fri 09 Jul 2010 08:50:26 AM PDT World Community Grid Temporarily failed upload of E200101_172_A.19.C14H8N4S.75.set1d06_1_4: HTTP error


I've took a sniff at what was happening to cause this error, and all I found was a TCP RST sent by the server (which, incidentally, Wireshark thinks is invalid -- it has a value in the ACK field, but the ACK flag is not set). The TCP connection was thus summarily ended. The server had ACKed a bunch of the segments, but partway through the <data> part of the transfer, instead of ACKing, it reset the connection.

I've got complete pcap traces of both a failed upload of an _4 file, and a successful up of _0, _1, _2, _3, _4, should that provide useful.