Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Ahoj,
jaká je prosím pravděpodobnost, že bych mohl zvrátit výsledek výše uvedeného příkazu. Partišna sdb2 byla ext4 a měla 322.5GB a byl v ní adresář /home a Idiotovi s rootovským oprávněním :'-( se jí povedlo přepsat obrazem obraz.img o velikosti asi 570MB.
Předpokládám, že už se mi z toho nepovede asi nic zachránit. Za případné nápady a rady předem děkuju.
Řešení dotazu:
Děkuju, určitě vyzkouším. Ale ke vší smůle ani nemám k dispozici disk kam bych případně obnovená data ukládal. Musím to zkusit jindy.
Moc děkuju, ale to nebude třeba. Už mám domluvenou výpujčku zítra u kámošky. Pak dám vědět jestli sem z toho něco dostal nebo ne. Jak jsem projížděl různý možnosti tak se určitě podívám na ten testdisk a photorec.
Všech rizik jsem si vědom. Těch dat je sice škoda, ale nezáleží na nich tolik, abych je pro získání osobních zkušeností nebyl ochoten obětovat Výsledek svých snah i s děkovačkami určitě napíši ...
ddrescue
.
S kopií počítám, ale ddrescue jsem vůbec nezaznamenal a přitom podle wiki vypadá, že je na takovou situaci přímo určený. Dík
Zkazit s tím snad nic nemůžu. A pokud dd přepsalo fyzicky jenom těch 600MB a alokační tabulku ext4, tak si myslím že by těch 322 GB dat bitová kopie s ddrescue měla zaznamenat. A když ne, tak udělám kopii s "obyčejným" dd. Až budu mít možnost poexperimentovat tak poreferuju.
ddrescue
to bylo zřejmě přestřelené. Pokusil bych se na tom disku najít alternativní superbloky a od některého začít. Třeba pomocí dumpe2fs
nebo pokud jsou přesně známy parametry s níž byl FS vytvářen tak mke2fs -n
tam opatrně! Bez paramteru -n se zničí všechno. Testdisk v advanced modu by je také měl najít.
Ahoj, tak už jsem něco málo vyzkoušel. Nejprve jsem si udělal s dd bs=2048 if=/dev/sdb2 of=obraz
obraz(trvalo to asi 4 hodinky). Dále jsem zkusil dumpe2fs
, ten hlásí:
Chybné magické číslo v superbloku při pokusu otevřít. Nemohu najít platný superblok v systému souborů.To hlásí u obrazu i u originálu. Dále jsem zkusil, jak radíš,
photorec
, který je velice úspěšný v hledání neúčelných dat jako je cache firefoxu, přitom výsledek vypadá jak bitva u Maglaje Ještě se po nějakých řešeních ve volných chvílích mrknu někde jinde, ale jak jsem čtl, že jméno příkazu dd se interpretuje jako "Data Destroyed" věděl jsem, že veškerá snaha bude marná. Tímto děkuji všem za ochotu a trpělivost.
Zjistím zkusím, jdu na to. Dík za tip
mkfs -n /dev/sda1
Typ OS: Linux
Velikost bloku=4096 (log=2)
Velikost fragmentu=4096 (log=2)
Krok=0 bloků, Šířka pásu=0 bloků
21127168 iuzlů, 84481536 bloků
4224076 bloků (5.00 %) rezervováno pro superuživatele
První blok dat=0
Maximum bloků v systému souborů=4294967296
2579 skupin bloků
32768 bloků ve skupině, 32768 fragmentů ve skupině
8192 iuzlů ve skupině
Zálohy superbloku uloženy v blocích:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968
dumpe2fs -o superblock=(zkusil jsem všechny čísla) /dev/sda1
Filesystem volume name: -none- Last mounted on: /media/bd5fcb24-19f8-4883-a03e-eeac27765545 Filesystem UUID: bd5fcb24-19f8-4883-a03e-eeac27765545 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 21127168 Block count: 84481535 Reserved block count: 4224076 Free blocks: 13335062 Free inodes: 20494852 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1003 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 RAID stride: 32748 Flex block group size: 16 Filesystem created: Fri Oct 26 13:37:54 2012 Last mount time: Sun Oct 19 19:20:10 2014 Last write time: Sun Oct 19 20:41:31 2014 Mount count: 0 Maximum mount count: -1 Last checked: Sun Oct 19 20:11:26 2014 Check interval: 0 (-none-) Lifetime writes: 2567 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 159f7744-7dc3-4866-a3af-c1806742b041 Journal backup: inode blocks Invalid argument při čtení superbloku žurnálu.Dělám něco špatně?
e2fsck -b zalozni_superblock /dev/device
. a případně také ten Testdisk pokud to umí undelete a ziskat soubory se smazaného oddílu. tak by to mohlo pomoci.
Na e2fsck
se mrknu zitra. Dik. Zatim mi aspon nejak fungoval ten photorec. Ale nenajde to vsechno a z ostatniho je dost bordelu. Ten testdisk
jak tady Jenda probiral, ze slouzi vyhradne k vyhledani souborovych systemu, tak jsem se jim nezabyval, protoze to uz mam vlastne prepsane tim obrazem. Jeste se tomu testdisku na ten manual podivam. Snad budu mit zitra chvili, ted pred tema Saturnaliema toho mam nejak moc.
Tak na tech strankach o TestDisku jsem se sice docetl, ze zvlada obnovu souboru, ale pouze z FAT, NTFS a ext2. Ja tam mival ext4 a u ext4 zvladne pouze vyhledat ztraceny oddil, coz asi u lehce prepsaneho nebude mozne. No zitra jeste mrknu na ten e2fsck
Děkuju. Přece jen pomohlo.
Dnes se mi podařilo z té partišny vydolovat zhruba 85% dat i s jejich původními jmény a někde i s původní adresářovou strukturou.
Podařilo se to pomocí těch záložních superbloků a skutečně toho testdisku. Po konečném experimentování dávám v plac všechny příkazy v kostce i se zálohováním oddílu a mountováním konečného obrazu:
dd if=/dev/sdb2 of=backup_sdb2.img mkfs -n backup_sdb2.img e2fsck -y -b zalozni_superblock backup_sdb2.img testdisk backup_sdb2.img mount -t ext4 backup_sdb2.img /mnt
Obraz oddílu je tedy mountován v adresáři /mnt a v něm je pak adresář lost+found, ve kterém jsou očíslované adresáře s více či méně uspořádaným původním obsahem. Pro srovnání PhotoRec z toho oddílu nenašel ani polovinu, natož aby to bylo uspořádáno.
Zase mám o něco více zkušeností, ale bráchu k tomu rootovskýmu účtu už stejně nepustím . Všem Vám moc děkuji za pomoc a přeji Veselé Vánoce.
Tiskni
Sdílej: