https://bugzilla.novell.com/show_bug.cgi?id=307098#c27
Michal Marek
(In reply to comment #20 from Michal Marek)
Actually libzypp downloads to a tmp file, which is then moved to the target destination, so this is not an issue.
It seems it is at last - the tmp file is 0 lenght if not modified and thus the target is overwritten with an empty file on copy.
Yeah, but at that time (after the transfer) you already have the response code, so you of course move only if it's not 304 (as you do in the patch) (In reply to comment #23 from Jan Kupec)
Just one more thing: is the timestamp of the file the only thing curl checks when CURL_TIMECOND_IFMODSINCE is used? So if i DO modify the file and reset the timestamp to the original, will curl still think it has not been changed? If so, is there a way to check for such situation?
You pass the timestamp (not some filename) stored in a long. The curl library doesn't care where you got the timestamp from and it assumes it's valid. (In reply to comment #24 from Jan Kupec)
Created an attachment (id=175753) --> (https://bugzilla.novell.com/attachment.cgi?id=175753) [details] CURL_TIMECOND_IFMODSINCE for doProvideFileCopy()
+ if (modified || infoRet != CURLE_OK) + { + // apply umask + if ( ::fchmod( ::fileno(file), filesystem::applyUmaskTo( 0644 ) ) ) + { + ERR << "Failed to chmod file " << destNew << endl; + } + ::fclose( file ); + + // move the temp file into dest + if ( rename( destNew, dest ) != 0 ) { + ERR << "Rename failed" << endl; + ZYPP_THROW(MediaWriteException(dest)); + } } + DBG << "done: " << PathInfo(dest) << endl;
Shouldn't the fclose() call be unconditional? Otherwise you could run out of filedescriptors. Also, in the not-modified case you can remove the zero-length tmp file. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.