Advanced Website Unix Wintertijd
Henk de Jong
remote files op mijn XS4ALL Advanced Website Unix een uur nieuwer zijn
dan mijn lokale files.
Is dit een bug in Dreamweaver, of staat er iets niet goed ingesteld op
de XS4ALL Advanced Website Unix server?
--
Met vriendelijke groet,
Henk de Jong
http://www.hsdejong.nl
Nepal and Myanmar (Burma) - Photo Galleries
Alex 10
> Sinds de wintertijd weer is ingegaan denkt Dreamweaver CS4 dat alle
> remote files op mijn XS4ALL Advanced Website Unix een uur nieuwer zijn
> dan mijn lokale files.
>
> Is dit een bug in Dreamweaver, of staat er iets niet goed ingesteld op
> de XS4ALL Advanced Website Unix server?
Ik heb net een test bestand aangemaakt via wh-shell op de ruimte
van een Adv. website Unix en krijg daarbij met een ls -la:
-rw------- 1 <username> user 6 Nov 11 13:57 b-test
te zien.
Ik vermoed dus dat Dreamweaver er met dat uur naast zit.
Al is er wel iets dat niet helemaal klopt, bij uitvoer van het
'date' commando op wh-shell is er ongeveer 3 minuten verschil
met de tijd waarmee ik een bestand aangemaakt heb.
Alex
Rob
> Al is er wel iets dat niet helemaal klopt, bij uitvoer van het
> 'date' commando op wh-shell is er ongeveer 3 minuten verschil
> met de tijd waarmee ik een bestand aangemaakt heb.
Toen wij nog een webhosting account bij XS4ALL hadden heb ik ook
wel eens gemeld dat de klok fout liep. Dat werd in dank aangenomen
en gelijkgezet maar kennelijk is er nog steeds geen NTP sync...
Henk de Jong
Synchroniseren in Dreamweaver doe ik met FTP.
Met een vandaag ge-upload bestand gaat het goed: lokaal en remote hebben
beide dezelfde datum en tijd, behalve dan inderdaad een verschil van 3
minuten.
Het gaat alleen verkeerd met bestanden die er al stonden voordat we
overgingen op wintertijd: alsof alle bestanden op de server een time
stamp hebben gekregen van plus 1 uur...
Alex 10
Unix machines gebruiken een timestamp van het aantal seconden sinds
1 januari 1970 UTC. De vertaalslag naar zomer/wintertijd daarvan gaat
dan niet goed in Dreamweaver denk ik.
Alex
Alex 10
> On 11-11-2009 14:02, Alex 10 wrote:
>> Henk de Jong wrote:
>>> Sinds de wintertijd weer is ingegaan denkt Dreamweaver CS4 dat alle
>>> remote files op mijn XS4ALL Advanced Website Unix een uur nieuwer zijn
>>> dan mijn lokale files.
>>>
>>> Is dit een bug in Dreamweaver, of staat er iets niet goed ingesteld op
>>> de XS4ALL Advanced Website Unix server?
>>
>> Ik heb net een test bestand aangemaakt via wh-shell op de ruimte
>> van een Adv. website Unix en krijg daarbij met een ls -la:
>> -rw------- 1 <username> user 6 Nov 11 13:57 b-test
>> te zien.
>>
>> Ik vermoed dus dat Dreamweaver er met dat uur naast zit.
>>
>> Al is er wel iets dat niet helemaal klopt, bij uitvoer van het
>> 'date' commando op wh-shell is er ongeveer 3 minuten verschil
>> met de tijd waarmee ik een bestand aangemaakt heb.
>>
>> Alex
>
> Synchroniseren in Dreamweaver doe ik met FTP.
> Met een vandaag ge-upload bestand gaat het goed: lokaal en remote hebben
> beide dezelfde datum en tijd, behalve dan inderdaad een verschil van 3
> minuten.
Unixbeheer zag inderdaad dat het op wh-shell afwijkt en gaat dat goed zetten,
afwijking was zo'n 177 seconden.
Alex
Henk de Jong
Voor de happy few die hier in ge�nteresseerd zijn vond ik een TechNote
http://kb2.adobe.com/cps/401/kb401070.html van Adobe zelf op het internet:
False warnings about files being newer on the server after Daylight
Savings Time changes
Issue:
When you Put or Synchronize files after time changes occur in the Spring
or Fall (for example U.S. Daylight Savings Time), Dreamweaver displays
the following false warning messages: "my_file.htm has changed on the
remote server since your last get or put operation. Putting it may
overwrite changes to the file. Do you wish to put the file anyway?"
This warning only occurs the first time you try to upload each file.
Subsequent uploads do not give this warning.
You may also experience similar problems with the Dreamweaver
synchronize feature if you change the time zone of your client machine,
for example, while traveling. (Ref. 202143)
Reason:
Dreamweaver assumes that the server's time zone will not change, which
is why this problem occurs during the Spring and Fall time changes.
Solution:
There are two possible solutions for this problem:
* Ignore the warnings and continue to put the files. You will only
see the warning the first time you upload each file. You will not see
the warning during subsequent uploads of each file.
* Turn synchronization off and then back on again, to re-create the
time stamps for your site. Because you will probably see the warnings
for all of the files on the server, this option is preferable:
1. Temporarily disable the "Maintain synchronization
information" option from the Remote Info category of the advanced view
of the Site Definition dialog box. This will delete all of the existing
time stamp information which is stored locally in hidden dwsync.xml files.
2. Close Dreamweaver.
3. Re-open Dreamweaver and go into the site definition dialog
box. Turn "Maintain synchronization information" back on. Dreamweaver
will now recreate the time stamp information as you transfer files
back-and-forth to and from the server.
Corné Beerse
> Sinds de wintertijd weer is ingegaan denkt Dreamweaver CS4 dat alle
> remote files op mijn XS4ALL Advanced Website Unix een uur nieuwer zijn
> dan mijn lokale files.
>
> Is dit een bug in Dreamweaver, of staat er iets niet goed ingesteld op
> de XS4ALL Advanced Website Unix server?
Met dreamweaver en websites heb ik geen ervaring, wel heb ik iets
vergelijkbaars gezien met de geheugenkaard uit mijn foto toestel:
De eerste import van de foto's in de wintertijd liet zien dat alle
foto's op de kaart een uur verschilden met de fotos in de directory.
Volgens mij komt dit door de mannier waarop msWindows met de tijd om
gaat: die gebruikt overal en nergens de lokale tijd, dus ook op de fat
en ntfs filesystemen. En dat gaat natuurlijk wel eens fout.
Als Bill Gates en consorten in de jaren 80 van de vorige eeuw niet zo
eigenwijs waren geweest maar beter om zich heen hadden gekeken dan zou
het probleem er niet geweest zijn, het probleem was toen al bekend en er
waren ook al oplossingen voor. Epoc begint niet voor niets op 1 januari
1970, 00:00 GMT. Epoc is de tijd registratie zoals bijvoorbeeld in unix
en bij ntp gebruikt wordt.
CBee
Rob
> Volgens mij komt dit door de mannier waarop msWindows met de tijd om
> gaat: die gebruikt overal en nergens de lokale tijd, dus ook op de fat
> en ntfs filesystemen. En dat gaat natuurlijk wel eens fout.
Dat heb je fout. Locale tijd wordt wel gebruikt op FAT filesysteem
maar niet op NTFS. Je zult op je fototoestel wel FAT hebben en op je
computer NTFS, en dan ontstaat er een verschil. In combinatie met
slecht gemaakte synchronisatie software geeft dat problemen.
Jurjen Oskam
> waren ook al oplossingen voor. Epoc begint niet voor niets op 1 januari
> 1970, 00:00 GMT. Epoc is de tijd registratie zoals bijvoorbeeld in unix
> en bij ntp gebruikt wordt.
Correctie: je bedoelt "epoch", en die term geeft aan wanneer een klok begon
met tellen. Zo is het Unix epoch inderdaad 01-01-1970,00:00 GMT, maar het
Windows epoch is 30 december 1899, het MacOS epoch is op 1 januari 1904,
enzovoort. Er is niet zoiets als "het" epoch. (Zolang we over operating
systems praten dan uiteraard.)
Waar jij waarschijnlijk op doelt is de beslissing van Microsoft om de
ingebouwde klok van een computer in lokale tijd bij te houden, in
tegenstelling tot GMT/UTC. Dat was inderdaad een nogal ongelukkige
beslissing.
--
Jurjen Oskam
Savage's Law of Expediency:
You want it bad, you'll get it bad.