Изпечатай

[mrowcp]

Здравейте,
Днес в сънено състояние, изтрих няколко папки с: rm -rf в които разбира се, имаше важни за мен неща.Та почнах да чета как мога да си възстановя информацията.
Първо опитах с debugfs , но не намери никакви файлове ( има ли значение дали съм излязъл/затворил конзолата през която съм изтрил файлове и за това да не намери нищо? ).
След това инсталирах testdisk - photorec и сканирах дяла, където се намираха изтритите неща, като зададох да запише всичко в /tmp.Намери доста файлове (като че ли повече от колкото изтрих), но тук идва и проблема: файловете са пръснати във всевъзможни папки с рандом имена (оказа, се че ги кръщава според вида и поредния номер).Казах си: добре пак е нещо, ще ги прегледам или сърчна с един

Код:

find /tmp -type f |xargs -exec grep 'tarsise' 

Еми да ама не намирам доста файлове за който съм 100% сигурен, че са там и търсения стринг го има .Интересно, че ми намира и файлове с разширение .dll .elf .mpg .avi в които го има търсения стринг 
Защо се получава така и кой е най-приятния начин/софтуер за възстановяване на файлове/директории конзолно?

[borovaka]

Аз до сега съм ползвал photorec, но този проблем с имената съм го имам винаги. Така като гледам това: http://extundelete.sourceforge.net/ би ти помогнало ( ако fs-a ти е ext3/4). Опитай и сподели дали работи наистина.

[mrowcp]

Аз до сега съм ползвал photorec, но този проблем с имената съм го имам винаги. Така като гледам това: http://extundelete.sourceforge.net/ би ти помогнало ( ако fs-a ти е ext3/4). Опитай и сподели дали работи наистина.

Код:

#./configure
Configuring extundelete 0.2.0
configure: error: C++ compiler cannot create executables
See `config.log' for more details.

#cat config.log
.............
.............
.............
configure:1905: g++    conftest.cc  >&5
./configure: line 1906: g++: command not found
configure:1908: $? = 127
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME "extundelete"
| #define PACKAGE_TARNAME "extundelete"
| #define PACKAGE_VERSION "0.2.0"
| #define PACKAGE_STRING "extundelete 0.2.0"
| #define PACKAGE_BUGREPORT "extundelete.sourceforge.net"
| #define PACKAGE "extundelete"
| #define VERSION "0.2.0"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:1947: error: C++ compiler cannot create executables
See `config.log' for more details.
............
............
............
## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE "extundelete"
#define PACKAGE_BUGREPORT "extundelete.sourceforge.net"
#define PACKAGE_NAME "extundelete"
#define PACKAGE_STRING "extundelete 0.2.0"
#define PACKAGE_TARNAME "extundelete"
#define PACKAGE_VERSION "0.2.0"
#define VERSION "0.2.0"

configure: exit 77

Идея?

[dejuren]

tarsise или tarsize?

Код:

find /tmp -type f |xargs -exec grep 'tarsise' 

Ама.... научете се да четете бре!

./configure: line 1906: g++: command not found

[borovaka]

@mrowcp Ако си с debian/ubuntu инсталирай build-essential и след това опитай отново да компилираш.

[mrowcp]

tarsise или tarsize?

Код:

find /tmp -type f |xargs -exec grep 'tarsise' 

Ама.... научете се да четете бре!

./configure: line 1906: g++: command not found

Ами аз го прочетох, но не го отразих мн мн Предположих, че ще измрънка "g++: command not found" или поне реда нещо, а не "configure: exit 77"

Иначе май е по-добре с extundelete, върна доста папки с оригиналните им имена.Файловете пак са с номера.Сега проблема е, че вече бях маунтнал дяла и писал върху него, което явно доведе до невъзможността да се ресторнат доста неща (програмата дава грешка, че едикое си име на файл не може да бъде ресторнато).

П.С. Интересно, че възстанови само .txt файлове и малко дирс.
П.С.2 tarsise - нещо да се търси.

[dejuren]

П.С.2 tarsise - нещо да се търси.

пробвай

Код:

find /dir -exec grep "string" {} \;

/off Общо взето влязохме в зоната на двата вида системни администратори - тези който правят бакъп и тези, които все още не правят... И на основното правило: никога rm -rf в сънено състояние или дори при подозрение за сънено ...

[Acho]

/off

Е сега и другiте ще правят. Дето сънени пишат rm -rf ...........

[mrowcp]

П.С.2 tarsise - нещо да се търси.

пробвай

Код:

find /dir -exec grep "string" {} \;

/off Общо взето влязохме в зоната на двата вида системни администратори - тези който правят бакъп и тези, които все още не правят... И на основното правило: никога rm -rf в сънено състояние или дори при подозрение за сънено ...

За бакъп има, но не е актуален.
Ще опитам и без xargs, макар че не виждам разлика.

ЕДИТ: по този начин не изписва "източника" където е намерило съвпадение, ако файла е текстови.Само пейства целия ред.

/off

Е сега и другiте ще правят. Дето сънени пишат rm -rf ...........

Така е.Поне "разцъках" няколко варианта за рестор.

[romeo_ninov]

ЕДИТ: по този начин не изписва "източника" където е намерило съвпадение, ако файла е текстови.Само пейства целия ред.

grep -l

[Acho]

Mrowcp, ти поне си сериозен човек, програмист, компютърджия, отдавна се занимаваш, не си някой безхаберник. Затуй се учудих много, ама как ще триеш с rm -rf наред по директориите ? Дано да си спасиш ценните неща колега.

[mrowcp]

ЕДИТ: по този начин не изписва "източника" където е намерило съвпадение, ако файла е текстови.Само пейства целия ред.

grep -l

Пак не е удобно както с xargs.

Код:

# find /tmp -exec grep -l 'upsd' {} \;
/tmp/recup_dir.19/f21477872.sh
/tmp/recup_dir.19/f21477976.txt
/tmp/recup_dir.19/f21461480.elf

и

Код:

# find /tmp -type f |xargs -exec grep 'upsd'
/tmp/recup_dir.19/f21477872.sh:/bin/killall upsd
/tmp/recup_dir.19/f21477872.sh:/usr/local/ups/bin/upsdrvctl start host
/tmp/recup_dir.19/f21477872.sh:/usr/local/ups/sbin/upsd
/tmp/recup_dir.19/f21477976.txt:Jan 24 23:03:58 host upsd[1370]: listening on 127.0.0.1 port 3493
/tmp/recup_dir.19/f21477976.txt:Jan 24 23:03:58 host upsd[1370]: Connected to UPS [host]: blazer_ser-host

Mrowcp, ти поне си сериозен човек, програмист, компютърджия, отдавна се занимаваш, не си някой безхаберник. Затуй се учудих много, ама как ще триеш с rm -rf наред по директориите ? Дано да си спасиш ценните неща колега.

Програмист чак не съм Изтрих ги точно при възстановяване на бекъп.Вътре в архива, папката се казваше по същия начин както оригиналната.Но вместо да напиша: rm -rf folder , аз се наказах с: rm -rf /folder

[dejuren]

Пак не е удобно както с xargs.

Код:

# find /tmp -exec grep -l 'upsd' {} \;
/tmp/recup_dir.19/f21477872.sh

и

Код:

# find /tmp -type f |xargs -exec grep 'upsd'
/tmp/recup_dir.19/f21477976.txt:Jan 24 23:03:58 host upsd[1370]: Connected to UPS [host]: blazer_ser-host

Това е така. Ще се върна малко към началото: ти си 100% сигурен, че стринга го има в някой файлове. Защо? По-добре провери ръчно. В случая ме съмняват твоите 100%

[Gogo_SZ]

Преди около година го имах с един клиент същия проблем (вярно с BSD ама и рой беше написал rm-Rf )
След 2-3 дни борба намерих един ама перфектен коментар по въпроса:

Цитат:  Командите в терминал се изпълняват винаги и от първи опит......

Съжалявам

[mrowcp]

Пак не е удобно както с xargs.

Код:

# find /tmp -exec grep -l 'upsd' {} \;
/tmp/recup_dir.19/f21477872.sh

и

Код:

# find /tmp -type f |xargs -exec grep 'upsd'
/tmp/recup_dir.19/f21477976.txt:Jan 24 23:03:58 host upsd[1370]: Connected to UPS [host]: blazer_ser-host

Това е така. Ще се върна малко към началото: ти си 100% сигурен, че стринга го има в някой файлове. Защо? По-добре провери ръчно. В случая ме съмняват твоите 100%

Защото някой са скриптове наследяващи променливи/команди от предни скриптове.Ще проверя ръчно пак, но за мен неща от рода на:

Код:

Binary file /tmp/recup_dir.24/f4134431.avi matches
Binary file /tmp/recup_dir.8/f17042856.elf matches
Binary file /tmp/recup_dir.8/f17047536.elf matches
Binary file /tmp/recup_dir.23/f50598080.elf matches
Binary file /tmp/recup_dir.23/f54802816.elf matches
Binary file /tmp/recup_dir.3/f9634446.mpg matches

ми се струват доста странни.Как може да намери съвпадение в .avi или .mpg?

ЕДИТ: сега видях, че има някакви .avi-та с подозрително еднаква големина:

Код:

-rw-r--r--.  1 root root 244428476 ЮОП 28 08:33 f13914367.avi
-rw-r--r--.  1 root root 244494650 ЮОП 28 08:33 f14869367.avi
-rw-r--r--.  1 root root 244576046 ЮОП 28 08:34 f15346903.avi
-rw-r--r--.  1 root root 244615686 ЮОП 28 08:34 f15824591.avi
-rw-r--r--.  1 root root 244603928 ЮОП 28 08:35 f16302359.avi

Утре ще видя дали могат изобщо да се пуснат.