Changes between Initial Version and Version 1 of Ticket #13135, comment 10
- Timestamp:
- Nov 21, 2015 2:53:54 AM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #13135, comment 10
initial v1 5 5 In our case, the timezone of the guest Linux was set to UTC (GMT), and the Mac host system was PDT (GMT-8). Strangely, you could change the timezone on Linux ("export TZ=PDT"), and it would still show the GMT time, except claim it was PDT. 6 6 7 So when Chrome asks for the file, the first thing it gets back is "not modified", so it doesn't re-fetch the file. BUT ... I think this is a bug in Chrome, it seems to use part of the changed file and/or the changed file's length. So you end up with parts of the new file injected into the older version, or random binary bytes at the end of the file.7 Thus, the file's modification time was off by eight hours. Ubuntu knew this, and Apache knew it, but it would report it to Chrome as GMT when in fact it was reporting PDT (or maybe vice versa?). 8 8 9 But you can use a different browser, or wget, or curl, or (as noted above) an incognito browser, and you get the correct file, which clearly indicates that VirtualBox isn't the problem. 9 So when Chrome asked "get me this file, but only if it's newer than this timestamp", it gets back is "not modified", so it doesn't re-fetch the file. BUT ... I think this is a bug in Chrome, it seems to use part of the changed file and/or the changed file's length. So you end up with parts of the new file injected into the older version, or random binary bytes at the end of the file. 10 11 You can use a different browser, or wget, or curl, or (as noted above) an incognito browser, and you get the correct file, which clearly indicates that VirtualBox isn't the problem. Firefox and Safari don't seem to have this problem, but Chrome does. 10 12 11 13 I fixed it by using "dpkg-reconfigure tzdata" and setting the timezone to "America/Los_Angeles", then rebooting the virtual box. Problem gone.
