I'm fairly certain it checks to see if the destination file exists before it attempts to retrieve last modified time - if the destination file doesn't exist then it should attempt the download anyway.
A bug fix was merged recently where the last-modified check wouldn't respect proxy settings if you were using a proxy - but that doesn't look like it applies to you. I mostly tested this with nginx but would be surprised if IIS is anything but well-behaved when it comes to correctly setting last-modified. Is there some network cleverness going on like squid or similar that might be confusing matter (although why it would not affect curl I can't imagine)? On Wednesday, April 5, 2017 at 11:42:43 PM UTC+1, cupcake wrote: > > the second curl is the difference of the file from the earlier one, so it > should have picked up but i see what you are saying if the other system is > 30 sec off or so it might now. > > I've just re-run it again and it still fails so it def should have picked > up by now. all three systems are EST and syncing to ntp; i can also auth > with kerberos. > > interestingly, if i change the url argument to say a new txt file instead > such as test.txt but keep the dest file the same on target, it still does > not copy the file over. > > # date > Wed Apr 5 18:29:13 EDT 2017 > > # curl -I http://windc1.foo.com/shares/test.txt > HTTP/1.1 200 OK > Content-Length: 5 > Content-Type: text/plain > Last-Modified: Wed, 05 Apr 2017 22:27:16 GMT > Accept-Ranges: bytes > ETag: "bb360c85baed21:0" > Server: Microsoft-IIS/7.5 > X-Powered-By: ASP.NET > Date: Wed, 05 Apr 2017 22:30:06 GMT > > > and then run now: > # date > Wed Apr 5 18:30:59 EDT 2017 > > ok: [winserver1.foo.com] => { > "changed": false, > "invocation": { > "module_name": "win_get_url" > }, > "win_get_url": { > "dest": "C:\\temp\\testfile.xml", > "url": "http://windc1.foo.com/shares/test.txt"; > } > } > > > This is a new txt file with different content and timestamp that is > "newer" than the other. If i fixup the dest to match the new file and do a > new run it copies: > changed: [winserver1.foo.com] => { > "changed": true, > "invocation": { > "module_name": "win_get_url" > }, > "win_get_url": { > "dest": "C:\\temp\\test.txt", > "url": "http://windc1.foo.com/shares/test.txt"; > } > } > > PLAY RECAP > ********************************************************************* > winserver1.foo.com : ok=2 changed=1 unreachable=0 > failed=0 > > > now add another line to the txt file on source win server and wait a few > minutes and still does not copy the changed file over. > # date > Wed Apr 5 18:36:23 EDT 2017 > > # curl -I http://windc1.foo.com/shares/test.txt > HTTP/1.1 200 OK > Content-Length: 5 > Content-Type: text/plain > Last-Modified: Wed, 05 Apr 2017 22:27:16 GMT > Accept-Ranges: bytes > ETag: "bb360c85baed21:0" > Server: Microsoft-IIS/7.5 > X-Powered-By: ASP.NET > Date: Wed, 05 Apr 2017 22:36:22 GMT > > # date > Wed Apr 5 18:40:13 EDT 2017 > > # curl -I http://windc1.foo.com/shares/test.txt > HTTP/1.1 200 OK > Content-Length: 16 > Content-Type: text/plain > Last-Modified: Wed, 05 Apr 2017 22:36:47 GMT > Accept-Ranges: bytes > ETag: "e1d1181c5daed21:0" > Server: Microsoft-IIS/7.5 > X-Powered-By: ASP.NET > Date: Wed, 05 Apr 2017 22:41:06 GMT > > ok: [winserver1.foo.com] => { > "changed": false, > "invocation": { > "module_name": "win_get_url" > }, > "win_get_url": { > "dest": "C:\\temp\\test.txt", > "url": "http://windc1.foo.com/shares/test.txt"; > } > } > > > > > > On Wednesday, April 5, 2017 at 6:10:58 PM UTC-4, J Hawkesworth wrote: >> >> Looks like there's only a few seconds there between the modification and >> the request (last example anyway). >> Just wondering if the clocks are in sync between the ansible controller >> and the windows box - they will need to agree on UTC for this to work. >> Also worth checking the timezones on both systems. >> Hope this helps, >> Jon >> >> >> On Wednesday, April 5, 2017 at 9:26:24 PM UTC+1, cupcake wrote: >>> >>> ansible 2.2.1.0 >>> windows server 2008 r2 x64 >>> >>> Trying to use win_get_url for an xml file update. I can curl the file >>> and see that it notices newer timestamp but force: no does not pull the new >>> file down. >>> >>> pbook: >>> >>> --- >>> # tasks file for packages >>> - name: >>> hosts: windows >>> tasks: >>> - name: Get XML file if newer >>> win_get_url: >>> url: 'http://windc1.foo.com/shares/testfile.xml' >>> dest: 'C:\temp\testfile.xml' >>> force: no >>> >>> >>> >>> curl original: >>> # curl -I http://windc1.foo.com/shares/testfile.xml >>> HTTP/1.1 200 OK >>> Content-Length: 123 >>> Content-Type: text/xml >>> Last-Modified: Wed, 05 Apr 2017 13:27:23 GMT >>> Accept-Ranges: bytes >>> ETag: "d9df35b10aed21:0" >>> Server: Microsoft-IIS/7.5 >>> X-Powered-By: ASP.NET >>> Date: Wed, 05 Apr 2017 20:16:03 GMT >>> >>> >>> >>> >>> >>> fresh run w no file pre-existing: >>> changed: [winserver1.foo.com] => { >>> "changed": true, >>> "invocation": { >>> "module_name": "win_get_url" >>> }, >>> "win_get_url": { >>> "dest": "C:\\temp\\testfile.xml", >>> "url": "http://windc1.foo.com/shares/testfile.xml"; >>> } >>> } >>> >>> >>> run again w no changes to origin: >>> ok: [winserver1.foo.com] => { >>> "changed": false, >>> "invocation": { >>> "module_name": "win_get_url" >>> }, >>> "win_get_url": { >>> "dest": "C:\\temp\\testfile.xml", >>> "url": "http://windc1.foo.com/shares/testfile.xml"; >>> } >>> } >>> >>> >>> >>> add line to xml and curl again: >>> # curl -I http://windc1.foo.com/shares/testfile.xml >>> HTTP/1.1 200 OK >>> Content-Length: 150 >>> Content-Type: text/xml >>> Last-Modified: Wed, 05 Apr 2017 20:17:46 GMT >>> Accept-Ranges: bytes >>> ETag: W/"b7d256b049aed21:0" >>> Server: Microsoft-IIS/7.5 >>> X-Powered-By: ASP.NET >>> Date: Wed, 05 Apr 2017 20:17:48 GMT >>> >>> >>> ok: [winserver1.foo.com] => { >>> "changed": false, >>> "invocation": { >>> "module_name": "win_get_url" >>> }, >>> "win_get_url": { >>> "dest": "C:\\temp\\testfile.xml", >>> "url": "http://windc1.foo.com/shares/testfile.xml"; >>> } >>> } >>> >>> >>> I saw some bugs regarding force: no not working properly on older >>> versions of ansible, but perhaps this issue still exists on 2.2.x. >>> >>> -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/bac43d15-e952-4491-86e9-39060debe446%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
