När man tar bort kataloger och står kvar i dem i terminalfönstret hanteras det i alla fall med LxTerminal ungefär som förväntat. Jag har alltid utgått från att den hanteringen helt varit i terminalen.
Ett mer oväntat beteende utesluter inte att den eller aktuellt beteende hanterats i terminalen men kan också indikera stöd närmare operativsystemets övergripande säkerhetsarkitektur. Och om inte intressant exempel kring exempel på hur säkerhetsprimitiver i logiska-regellager där man mer trivialt försöker fånga brott mot "rimlighet" i en sund säkerhetsarkitektur ett av de sista lagren (eller i antivirus-scam-branschen oftast det enda lagret tillsammans med trivial sträng-matchning).
- Operativsystem är Ubuntu med fönsterhanteraren LXDE (prestanda-optimerad - "LXDE is a faster and less resource hungry free and open source desktop environment." - men gör för de flesta troligen liten skillnad om man inte pressar miljön av och till med andra processer eller använder en äldre datorer) som fönsterhanterare, och LxTerminal som terminal.
- Önskar samla information avseende ett kontext i resp. fil.
- Missar att skapa en underkatalog för dessa som snabbt verkade bli väldigt många.
- Flyttar filer jag behöver ha kvar (själva Perl-skriptet genereringen gjordes med) till en temp-katalog.
- Raderar den ursprungliga katalogen för att snabbt få bort alla kontext-filer.
- Skapar katalogen igen.
- Både raderandet och skapandet av katalogen gjordes via Nautilus (d.v.s. inte default filemanager för LxTerminal vilken jag tycker genom dålig integration med fönsterhanteraren suger ännu mer än vad Nautilus gör via sunkigt ineffektivt hanterande av systemresurser och särskilt minne innebärande att jag hellre tar att jag behöver döda Nautilus om jag vill gå nära maximal mängd minne som kan allokeras samtidigt).
- Står fortfarande kvar i samma katalog i terminalfönstret under hela processen.
- Återskapar skript-filen med meta-x i Emacs.
- Kör skript-filen i samma terminalfönster vilket går utmärkt: Ingen felinformation relaterat skapandet av filer m.m. eller i övrigt. Allt går 100% normalt så vitt skriptet kan se.
Emellertid har inga filer skapats. Inte någonstans i skriptet användes default-referering till standard-out eller liknande. Alla handles skapades explicit, felhanterades och refererades alltid explicit.
Har tycks med andra ord en komponent OS eller näraliggande OS (typiskt troligast för det senare LxTerminal) upptäckt att katalogen försvunnit antingen pol-kontroll eller ev. meddelats (om det nu är möjligt och om så införts: tvivlar lite på det för ett ändå tämligen effektivt OS med mycket av ansvar på applikationerna jfr ex. Microsoft Windows). Själv hade jag spontant utgått från att sådan kontroll i terminalen först skedde när den explicit ombetts gå till ett tillstånd ej längre möjligt.
Därefter blir den ombedd att köra skriptet. Det fungerar: skriptet finns på förväntad plats.
Något noterar dock att katalogen försvunnit och att något ändå körs där. Ev. noterar den att katalogen tycks finnas kvar men litar inte 100% på det förrän jag explicit direkt efteråt för den andra körningen gör:
- $ cd..
$ cd /VERB_COMMON_SENSE
Och därefter kör skriptet igen nu både fungerande och med faktiska filer skapade.
Känns som en säkerhetsprimitiv för hantering race conditions. Om så långt ifrån otroligt i bash-tolken (eller vilken jag nu kör) ev. "kross-kompilerat" via vilken metod som nu Linux vanligen använder för delad OS-nära funktionalitet (jfr DLL-filer m.m. i Microsoft Windows) eller alt. antagligen troligare indirekt i abstrakta OS-API:er för funktioner inkluderande något krävt för att vissa operationer ska tillåtas.
Om så kan vi spekulera att det ev. hade räckt att kanske vänta en viss även om jag egentligen tror att det inte generellt klarar att hantera race conditions av de typer som av och till varit aktuella åtminstone de senaste 20 åren för Unix och Linux men ibland missförstådda vara tidsberoende på sätt som operativsystemet kan hantera genom att vänta, släppa skydd efter en viss tid o.s.v.
Foto:
Kommentera