Fórum Root.cz
Hlavní témata => Windows a jiné systémy => Téma založeno: Lukáš598 11. 10. 2017, 17:59:43
-
Ahoj. Chtěl bych se zeptat proč se neakceptují změny souborů které změním pokud Bash Ubuntu běží. Když restartuji Apache2 tak se php, html atd.. soubory načtou správně.
-
No, to jsem teda napsal dotaz jako prase :P Tak znova...
Spustím terminál Bash Ubuntu
v tomto terminálu spustím Apache2
pak vložím do souboru /var/www/html/index.html text třeba AAA
uložím a v prohlížeči zadám http://locahost
načte se AAA
- doposud OK -
teď spustím průzkumníka ve Windows a do souboru /var/www/html/index.html vložím text třeba BBB
uložím a v prohlížeči zadám http://locahost
načte se opět AAA
přepnu do termínálu Bash Ubuntu
a zadám cat /var/www/html/index.html
a je tam BBB
Tak proč není i v prohlížeči?
-
Není to normální síťová cache pro webové stránky? Zkuste změnit v průzkumníku, otevřít v prohlížeči a tam dát F5 či Ctrl+F5
-
Cache ?
-
Keší to není, neprojeví se to ani v jiném prohlížeči kde jsem localhost nikdy nezadával, zkoušel jsem i cache vymazat.
-
Tak asi nepujde o cache prohlizece, ale o cache Apache. Bud ho musite restartovat nebo nejak jinak donutit ke znovunacteni souboru. Coz, pokud umi, bude asi nekde v manualu.
-
Cache Apache se mi moc nezdá, není k tomu důvod, aby to držel někde explicitně nacacheované. Ale je možné, že drží otevřený soubor, a že ten editor ve Windows ve skutečnosti udělá to, že původní soubor smaže a zapíše nový se stejným názvem. Mělo by to být vidět v adresáři /proc příslušného procesu Apache – v podadresáři fd je seznam otevřených souborů, uvidíte, zda tam bude odkaz na ten váš soubor a případně zda bude označený jako deleted.
-
@Filip Jirsák:
A co treba:
The MMapFile directive of mod_file_cache maps a list of statically configured files into memory through the system call mmap(). This system call is available on most modern Unix derivatives, but not on all. There are sometimes system-specific limits on the size and number of files that can be mmap()ed, experimentation is probably the easiest way to find out.
This mmap()ing is done once at server start or restart, only. So whenever one of the mapped files changes on the filesystem you have to restart the server (see the Stopping and Restarting documentation). To reiterate that point: if the files are modified in place without restarting the server you may end up serving requests that are completely bogus. You should update files by unlinking the old copy and putting a new copy in place. Most tools such as rdist and mv do this. The reason why this modules doesn't take care of changes to the files is that this check would need an extra stat() every time which is a waste and against the intent of I/O reduction.
Jestli index.html je defaultne mapovany do pameti, protoze se predpoklada zmena jednou za uhersky rok.....?
-
@Filip Jirsák:
A co treba:
…
To je přesně to, co jsem napsal. Soubor není nijak explicitně cachovaný Apachem, ale Apache ho drží otevřený. A pokud dojde ke smazání souboru a vytvoření nového souboru se stejným jménem, Apache to kvůli implementaci souborových systémů na Linuxu nezjistí, protože má stále odkaz na ten původní soubor (který už po smazání není dostupný pod žádným jménem, ale protože na něj ještě existuje v Apachi odkaz, nedojde k jeho fyzickému smazání).
-
To je přesně to, co jsem napsal.
;D ;D ;D ;D ;D
-
@Filip Jirsák:
A co treba:
…
To je přesně to, co jsem napsal. Soubor není nijak explicitně cachovaný Apachem, ale Apache ho drží otevřený. A pokud dojde ke smazání souboru a vytvoření nového souboru se stejným jménem, Apache to kvůli implementaci souborových systémů na Linuxu nezjistí, protože má stále odkaz na ten původní soubor (který už po smazání není dostupný pod žádným jménem, ale protože na něj ještě existuje v Apachi odkaz, nedojde k jeho fyzickému smazání).
Tenhle nesmysl vznikl jak?
Protoze apache urcite nedrzi soubor otevreny a urcite neblokuje fyzicke smazani souboru...
-
...
A kdyz ten soubor zmenis v tom bashi? Ony maj totiz widle takovy ty ubefrikulinsky vymozenosti ktery vecne nefungujou na tema offline files, a trebas to nejak pouzivaj i na tohle.
-
@Filip Jirsák:
A co treba:
…
To je přesně to, co jsem napsal. Soubor není nijak explicitně cachovaný Apachem, ale Apache ho drží otevřený. A pokud dojde ke smazání souboru a vytvoření nového souboru se stejným jménem, Apache to kvůli implementaci souborových systémů na Linuxu nezjistí, protože má stále odkaz na ten původní soubor (který už po smazání není dostupný pod žádným jménem, ale protože na něj ještě existuje v Apachi odkaz, nedojde k jeho fyzickému smazání).
Tenhle nesmysl vznikl jak?
Protoze apache urcite nedrzi soubor otevreny a urcite neblokuje fyzicke smazani souboru...
Tenhle nesmysl vznikl tak, že tady napsal svou spekulaci či hypotézu (nebo co to bylo) Filip Jirsák, bez toho, že by to podpořil nějakými reálnými podklady. A napsat ji takto mohl jen proto, že tazatel nedal k dispozici moc informací, což pak nahrává tomu, že si kde kdo může napsat kde co, bez toho, že by se to opíralo o něco opravdu reálného.
-
...
A kdyz ten soubor zmenis v tom bashi? Ony maj totiz widle takovy ty ubefrikulinsky vymozenosti ktery vecne nefungujou na tema offline files, a trebas to nejak pouzivaj i na tohle.
Já osobně bych to taky jako jednu z možností hledal někde mezi těmi Windows a "emulací" linuxových jaderných volání, umožňujících provoz nativních linuxových binárek ve Windows. Taky bych zkouknul configuraci spuštěného apache a taky bych zkusil, jestli se to při změně souboru přímo v linuxovém "sandboxu" než abych ten soubor měnil přímo ve Windows.
-
https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/
-
Protoze apache urcite nedrzi soubor otevreny
V komentáři výše od JardyP. máte popsán jeden z případů, kdy Apache drží otevřený soubor.
urcite neblokuje fyzicke smazani souboru...
Souborové systémy na Linuxu (a na Unixem obecně) fungují tak, že je někde na disku uložený soubor (tj. samotná data souboru, jeho obsah), a na ten soubor existuje jeden nebo více odkazů. Odkazy jsou například jména souborů v adresářích – nebo-li když máte nějak pojmenovaný soubor na disku, je to právě odkaz na ta data soubor. Když vytvoříte hardlink na soubor, není to nic jiného, než že do nějakého adresáře přidáte další odkaz na ten soubor (tj. na jeden obsah souboru vedou dva různé odkazy). A také každý program, který má otevřený nějaký soubor, má odkaz na ten soubor. Souborový systém pak funguje tak, že se soubor (tj. jeho obsah) fyzicky smaže teprve tehdy, když počet odkazů na soubor klesne na nulu. Takže když smažete nějaký soubor (např. pomocí příkazu rm), smaže se ten odkaz z adresáře – ale pokud na soubor vede nějaký další odkaz, třeba ze spuštěného programu, soubor dál na disku zůstává. Nebo-li můžete mít na disku soubor, ke kterému nevede žádná cesta ze souborového systému (myšleno teď přímo ze souborového systému na diskovém oddílu, ponechme stranou speciální souborové systémy jako /proc). Takže například pokud vám nějaký program bude chrlit spoustu dat do logu a bude docházet místo na disku, vy soubor s logem smažete, ale žádné místo na disku se neuvolní, protože na soubor s logem stále vede odkaz z toho programu a ten do logu vesele dál zapisuje. Nebo-li dokud jakýkoli program v Linuxu má otevřený nějaký soubor, brání fyzickému smazání toho souboru, protože počet odkazů na soubor nemůže klesnout na nulu.
-
Tenhle nesmysl vznikl tak, že tady napsal svou spekulaci či hypotézu (nebo co to bylo) Filip Jirsák, bez toho, že by to podpořil nějakými reálnými podklady. A napsat ji takto mohl jen proto, že tazatel nedal k dispozici moc informací, což pak nahrává tomu, že si kde kdo může napsat kde co, bez toho, že by se to opíralo o něco opravdu reálného.
V dalších komentářích tazatel informace doplnil:
Za prvé, starou verzi souboru zobrazují i jiné prohlížeče, kde stránka předtím nebyla zobrazena – takže nemůže jít o cache v prohlížeči. Mohla by to ještě dělat nějaká cache mezi prohlížečem a serverem, ale dá se předpokládat, že to tazatel zkouší přímo. Nebo-li je vysoce pravděpodobné, že starou verzi souboru servíruje přímo server.
Za druhé, když tazatel zkusí zobrazit soubor příkazem cat přímo z Linuxu, zobrazí se nová verze. Takže to není žádný problém v té emulační vrstvě mezi Windows a Linuxem (leda že by různým programům poskytovala různé verze souborů, ale to by byl fakt úlet). No a případ, kdy v Linuxu vidí dva programy různá data v jednom souboru, nastává právě tehdy, když program drží soubor otevřený, jiný program ten soubor smaže a na jeho místě vytvoří nový, se stejným názvem (což je u Windowsovských editorů typický postup). Původní program pak stále vidí ten soubor, který původně otevřel (a který už nemusí mít žádné jméno), nově spuštěný program použije cestu k souboru pro získání ukazatele, ale cesta už vede na nový soubor.
Takže zbývá vyřešit, proč Apache drží ten soubor otevřený – jednu z možných odpovědí citoval JardaP.
Pokud nějaký program drží otevřený soubor přes souborový deskriptor, je vidět v adresáři /proc/<PID>/fd/. mmap ale má v Linuxu svůj vlastní odkaz na soubor a původní souborový descriptor je po volání mmap možné zavřít, takže pokud Apache soubor drží přes mmap, v /proc/<PID>/fd to vidět nebude – je ale možné to najít v souboru /proc/<PID>/maps.
-
Nebylo by lepší si místo těch bludů přečíst ten odkaz na MS? ::)
-
@Filip Jirsák:
A co treba:
…
To je přesně to, co jsem napsal. Soubor není nijak explicitně cachovaný Apachem, ale Apache ho drží otevřený. A pokud dojde ke smazání souboru a vytvoření nového souboru se stejným jménem, Apache to kvůli implementaci souborových systémů na Linuxu nezjistí, protože má stále odkaz na ten původní soubor (který už po smazání není dostupný pod žádným jménem, ale protože na něj ještě existuje v Apachi odkaz, nedojde k jeho fyzickému smazání).
No, jede to na NTFS a pres widlovy ovladac FS, takze bych si neroufal tvrdit, ze to takto funguje, protoze nemam tuseni, jak to na tech Widlich v tomto pripade je.
-
Nebylo by lepší si místo těch bludů přečíst ten odkaz na MS? ::)
Bylo, netuším, proč to neuděláte. Můžu vám tu i jeden odstavec vypíchnout:
Further, as in Linux, some Windows tools implement unusual filesystem access patterns to handle file updating and don't actually edit files in-place: When apps/tools save changes to a file, the original files are often deleted and re-created, etc. During such operations, NT file extended properties (i.e. Linux file permissions) are often not copied and are "lost".
Už to tu máte vysvětlené potřetí, tak třeba to vezmete na vědomí…
-
No, jede to na NTFS a pres widlofy ovladac FS, takze bych si neroufal tvrdit, ze to takto funguje, protoze nemam tuseni, jak to na tech Widlich v tomto pripade je.
To počítání odkazů není vlastností jednotlivých souborových systémů (btrfs, ext4 apod.), ale přímo součástí VFS. Třeba když je spuštěný program, který drží otevřený soubor, na souborovém systému na disku se to nijak neprojeví – je to informace, kterou si udržuje VFS v paměti.
-
@Filip Jirsák: A vy vite s jistotou, ze v linuxovem subsystemu na Widlich to funguje take tak?
-
@Filip Jirsák: A vy vite s jistotou, ze v linuxovem subsystemu na Widlich to funguje take tak?
Jistě. Není tak těžké si to vyzkoušet. A navíc by to těžko mohlo fungovat jinak.
-
Jistě. Není tak těžké si to vyzkoušet. A navíc by to těžko mohlo fungovat jinak.
Vzhledem k tomu, ze je to bastl od MS, tak bych si radsi nebyl nicim jisty.
-
Nebylo by lepší si místo těch bludů přečíst ten odkaz na MS? ::)
To by nešlo, Jirsák postupuje podle těchto bodů:
1. Jirsák má vždycky pravdu
2. Pokud Jirsák pravdu nemá, platí pravidlo č. 1
3. Dodatek: Jirsák má vždycky pravdu i kdyby se prokázalo, že je blbej
Ad 3. V takovém případě je nutné pokusit se zahltit a zmást ostatní diskutující pouze okrajově souvisejícími informace, které jsou platné a které někde vyčetl a pokusit se tak zvrátit co už všichni vědí. ;D
-
Vzhledem k tomu, ze je to bastl od MS, tak bych si radsi nebyl nicim jisty.
Já jsem to zkoušel na Ubuntu pod Windows 10 s vimem – ve vimu jsem otevřel soubor s NTFS svazku (/mnt/c/…), vim si vytvoří pracovní soubor .nazev.swp. Podíval jsem se do /proc/<vim-pid>/fd/, tam je vidět otevřený deskriptor souboru, v průzkumníkovi ve Windows se v příslušném adresáři objevil soubor .nazev.swp. Z průzkumníka jsem ho smazal, v Ubuntu už ten název souboru také neexistoval (ověřeno výpisem ls -la), ale link v /proc/<vim-pid>/fd/ stále existoval – a cat /proc/<vim-pid>/fd/ vypsal očekávaný obsah pracovního souboru vimu. Chovalo se to tedy přesně podle očekávání a úplně stejně, jako na čistokrevném Linuxu běžícím přímo na železe. mmap jsem nezkoušel, ale nemám žádný důvod myslet si, že by to mělo fungovat jinak.
S dovolením budu tedy raději věřit tomu, co jsem si sám vyzkoušel, než vašim pochybám, které nemáte podložené žádným experimentem nebo dokumentací.
To by nešlo, Jirsák postupuje podle těchto bodů:
Chápu vaši frustraci z toho, že jsem si vám dovolil oponovat, vám, který si o sobě myslíte, že jste mistr světa. Nicméně to, že si někdo dovolí oponovat vám, opravdu neznamená, že si dotyčný myslí, že má vždy pravdu. Ostatně pokud si myslíte, že pravdu nemám, napište konkrétně, v čem se mýlím, jak je to podle vás – a ideálně také něco, čím svůj názor podpoříte. Zatím tady na tazatelův dotaz padly dvě relevantní odpovědi – že soubor cachuje prohlížeč, což tazatel následně vyvrátil, a druhá odpověď byla, že z nějakého důvodu starý obsah posílá server. Já jsem vysvětlil, v jakém případě a proč server může posílat starý odkaz, JardaP. to doplnil citací o mod_file_cache a Majkl to doplnil odkazem na MSDN, v obou případech jsou popisovány stejné principy, o kterých jsem psal já. Nikdo tahle tvrzení nevyvrátil ani nenapsal nebo neodkázal nic, co by s nimi bylo v rozporu.
Takže pokud jste přesvědčen, že se mýlím, protože ten geniální jste tu přece vy ne nemůže být nikdo, kdo by se vám alespoň přiblížil, dokažte to. Dokažte, že se mýlím, a neztrapňujte se tu podsouváním věcí, které jsem nikdy netvrdil. Ten váš předpoklad, že Jirsák nikdy nemůže mít pravdu, totiž nevypovídá nic o mně, jenom o vás.
-
...
Koukam Jirsakovo blabolivy kolecko opet zacina. Mimochodem jirsaku, Apache zadnej html soubor otevrenej nema ani mit nemuze. On ho bud veme, a posle v okamzik pozadavku, a pripadne si ho jeste navrch ulozi do cache, ale rozhodne ho nedrzi otevrenej protoze pro to neexistuje naprosto zadnej duvod. Teda s jedinou vyjimkou - ze by tvurci apache byli stejni blbci jako TY.
https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/
Lol ... takze je to jeste horsi, nez sem si myslel.
-
pripadne si ho jeste navrch ulozi do cache
Proč by takovou hloupost dělal, když to může mít v cache operační systém? Aby se pokud možno zaplnila paměť, přeteklo to do swapu a ta data, která jsou už jednou na disku, se pro jistotu zapsala na disk ještě podruhé a příště by se četla z disku?
ale rozhodne ho nedrzi otevrenej
To nepište mně, to běžte napsat autorům Apache – zjevně totiž nevědí, co dělají (https://httpd.apache.org/docs/2.4/caching.html).
Kdybyste aspoň tušil, o čem je řeč, věděl byste, jak triviální je ověřit si to, co tady píšu. Mohl byste mi prozradit, kde se podle vás ve výpisu deskriptorů souborů Apache vzal ten deskriptor č. 5?
root@desktop:~# a2enmod file_cache
Considering dependency cache for file_cache:
Enabling module cache.
Enabling module file_cache.
To activate the new configuration, you need to run:
service apache2 restart
root@desktop:~# echo 'CacheFile /var/www/html/index.html' >> /etc/apache2/apache2.conf
root@desktop:~# service apache2 restart
* Restarting Apache httpd web server apache2
root@desktop:~# ls -l /proc/25129/exe
lrwxrwxrwx 1 root root 0 říj 13 19:57 /proc/25129/exe -> /usr/sbin/apache2
root@desktop:~# ls -l /proc/25129/fd/
celkem 0
lr-x------ 1 root root 0 říj 13 19:58 0 -> /dev/null
l-wx------ 1 root root 0 říj 13 19:58 1 -> /dev/null
l-wx------ 1 root root 0 říj 13 19:58 2 -> /var/log/apache2/error.log
lrwx------ 1 root root 0 říj 13 19:58 3 -> /unknown
lrwx------ 1 root root 0 říj 13 19:58 4 -> /unknown
lr-x------ 1 root root 0 říj 13 19:58 5 -> /var/www/html/index.html
lr-x------ 1 root root 0 říj 13 19:58 6 -> pipe:[21343]
l-wx------ 1 root root 0 říj 13 19:58 7 -> pipe:[21343]
l-wx------ 1 root root 0 říj 13 19:58 8 -> /var/log/apache2/other_vhosts_access.log
l-wx------ 1 root root 0 říj 13 19:58 9 -> /var/log/apache2/access.log
protoze pro to neexistuje naprosto zadnej duvod
Existuje, a to zrychlení přístupu k souboru.
-
Proč by takovou hloupost dělal, když to může mít v cache operační systém? Aby se pokud možno zaplnila paměť, přeteklo to do swapu a ta data, která jsou už jednou na disku, se pro jistotu zapsala na disk ještě podruhé a příště by se četla z disku?
A proc cachuji browsery? Ze by proto, ze cache OS pro dane pouziti nevyhovuje?
-
A proc cachuji browsery? Ze by proto, ze cache OS pro dane pouziti nevyhovuje?
To je ale úplně jiná cache. Browsery lokálně cachují data, která by jinak musely znovu stahovat ze sítě. Ta data uloží do souboru na disk. Nevím o to, že by nějaký prohlížeč data, která má na disku, ještě duplicitně držel v paměti.
Disková cache OS funguje tak, že když nějaký proces čte data ze souboru, OS je načte do paměti, a nechá je tam i po té, kdy je proces přečetl – dokud není paměť potřeba pro něco důležitějšího. Stahovat soubory přes HTTPS OS opravdu neumí.
-
[...]Nevím o to, že by nějaký prohlížeč data, která má na disku, ještě duplicitně držel v paměti.
Dela to kazdy prohlizec, rika se tomu "pametova cache" ;-)
-
Jirsáku, jasně jsem ti říkala, že se nemáš vyžvaňovat po internetu -- koukej vyluxovat, umejt nádobí a vynes koš, zejtra přijedu hned ráno!!!
-
To je ale úplně jiná cache. Browsery lokálně cachují data, která by jinak musely znovu stahovat ze sítě. Ta data uloží do souboru na disk. Nevím o to, že by nějaký prohlížeč data, která má na disku, ještě duplicitně držel v paměti.
Hm, kampak se asi ztrati veskera ta pamet, kdyz pustim browser a chvili lezu po webu?
-
Dela to kazdy prohlizec, rika se tomu "pametova cache" ;-)
Hm, kampak se asi ztrati veskera ta pamet, kdyz pustim browser a chvili lezu po webu?
To ale není cache souborů – opravdu nedává smysl cachovat v paměti to, co už jednou cachuje operační systém, a akorát tím zbytečně zabírat paměť. Zkuste si to představit, pokud byste měli paměť jen na dva soubory. Buď se vám tam vejde soubor A nacachovaný v OS a ten samý soubor A podruhé nacachovaný v prohlížeči, nebo se vám tam vejdou soubory A a B nacachované v OS. Lepší je samozřejmě druhá varianta, protože když budete chtít načíst soubor A, v obou případech ho načtete z paměti, ale když budete chtít načíst soubor B, v prvním případě ho musíte načíst z disku a v druhém případě z paměti. Což je samozřejmě rychlejší, proto se to cachování souborů v paměti dělá. Navíc v tom prvním případě by se pro načtení souboru B nejdříve musela nějaká paměť uvolnit, např. zapsat do swapu. Takže by se klidně mohlo stát, že soubor A, který už máte na disku a dokonce ještě v jiném místě paměti, by se úplně zbytečně zapisoval do swapu. A až by ho ten proces chtěl zase číst, musel by se zase načíst ze swapu na disku – přestože vedle by byl ten samý obsah v paměti v cache OS.
To, co cachují prohlížeče v paměti, je DOM (rozparsované a načtené stránky), rozparsovaný a případně zkompilovaný JavaScript, případně jiné už předzpracované objekty.
Cache je obecný pojem, existuje spousta různých druhů cache, takže když máte dva různé cachovací mechanismy, neznamená to, že by cachovaly to samé – naopak by to bylo neefektivní. Už tady byly zmíněné tři různé cache – prohlížeč si lokálně cachuje soubory, aby je nemusel stahovat z internetu; OS cachuje data načtená z disku do paměti, aby je nemusel načítat znovu z disku, když je bude chtít nějaký proces číst; prohlížeč cachuje předzpracované objekty (webové stránky, skripty), aby je nemusel znovu parsovat a překládat nebo interpretovat, když bude chtít uživatel zobrazit danou stránku. Dál prohlížeč cachuje třeba výsledky DNS dotazů – to ale vůbec neznamená, že by to mělo něco společného se souborovou cache OS.
-
Za chvíli jsem u vás, ty se budeš divit, Jirsáku!!!
(https://image.prntscr.com/image/UAZhUAZbTVGLJG6HW81cLQ.jpg)
-
....prohlížeč si lokálně cachuje soubory, aby je nemusel stahovat z internetu; ...
Jo. A pak si je jeste cachuje na disku, odkud je cachuje OS a pak pro jistotu dost mozna jeste ten prohlizec.
-
No a nemuze to bejt treba pege cache?
-
https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/
Lol ... takze je to jeste horsi, nez sem si myslel.
Můžete být o něco konkrétnější, co je v tom odkazu tak hrozného?