Bagaimana saya bisa menghapus folder `found.002` ini di Win Vista?


1

Sistem di laptop saya adalah Windows Vista. Saya tidak dapat menghapus found.002 map. Apa itu dan bagaimana saya bisa menghapusnya?

saya telah mencoba del found.002. Tetapi tidak berhasil sama sekali.

enter image description here

EDIT: Berkat jawabannya, saya bisa menghapus folder found.002 dan found.003. Tetapi saya tidak dapat melakukannya untuk itu found.004. Karakter pada gambar kedua berarti "Akses ditolak" dalam bahasa Inggris.

enter image description here

Jawaban:


2

Anda dapat menghapus folder melalui Explorer, atau dari baris perintah sebagai: rd /s /q found.002 atau apa pun foldernya.

Perlu diingat bahwa rd /s /q akan sepenuhnya menghapus direktori tanpa konfirmasi, jadi pastikan Anda ingin menghapus direktori ini sebelum menjalankannya.


Terima kasih atas jawaban anda. Saya telah berhasil menghapus folder found.002 dan found.003. Tetapi ketika saya mencoba found.004, itu ditunjukkan access denied.
Jack

2
@Jack: Buka Command Prompt yang lebih tinggi ("Jalankan sebagai Administrator" dalam versi bahasa Inggris), lalu coba lagi. Jika masih tidak berhasil, gunakan ambil kepemilikan menggunakan takeown /f found.004, kemudian rd harus mulai bekerja.
grawity

@grawity: Masih tidak berfungsi. Saya telah mengedit pertanyaan sesuai.
Jack

@ Jack: Oh, mungkin takeown /f /r found.004 akan membantu. Saya lupa menambahkan /r untuk mode "rekursif".
grawity

1
Sebagai @grawity Anda harus mencoba mengambil kepemilikan terlebih dahulu, setel ulang ACL & amp; lalu coba hapus gist.github.com/972013
Sathyajith Bhat

3

Sejarah

Pada zaman MS-DOS dan PC-DOS, itu chkdsk utilitas, ketika memulihkan file yang hilang (mis. file yang masih memiliki ruang yang dialokasikan untuk mereka dalam FAT tetapi tidak terdaftar di direktori mana pun), itu akan membuat entri direktori untuk mereka di direktori root, bernama FILE nnnn .CHK dan DIR nnnn .CHK . Pada saat itu, fsck Sebaliknya, program Unices menempatkan file-file yatim yang ditemukan di sub-direktori root bernama lost+found.

Ini chkdsk strategi yang buruk karena beberapa alasan, tidak sedikit di antaranya adalah bahwa pada volume FAT12 dan FAT16 direktori root memiliki ukuran tetap, dan tidak panjang variabel seperti direktori lain. Jika ada terlalu banyak file yang hilang, chkdsk akan berakhir mengisi direktori root. Maka tibalah saat ketika IBM dan Microsoft mengeluarkan HPFS, yang ada di OS / 2 versi 1.2, sebuah perubahan dilakukan, karena memberikan dukungan HPFS diperlukan perbaikan besar-besaran alat seperti chkdsk, format, sys, dan recover bagaimanapun.

Versi OS / 2 dari chkdsk dengan demikian diimplementasikan untuk melakukan apa fsck melakukan. Itu menciptakan subdirektori di direktori root, dan menempatkan entri direktori baru untuk file yang dipulihkan di sana. Itu tidak menggunakan nama subdirektori tetap, seperti fsck memang demikian. Alih-alih mencoba membuat found. nnn direktori, di mana nnn mulai di 000 dan bertambah hingga tidak berbenturan dengan subdirektori yang ada. Dalam direktori itu akan menjadi semua FILE nnnn .CHK dan DIR nnnn .CHK file. Masih dimungkinkan untuk mengisi direktori root (pada FAT12 dan FAT16) - HPFS tidak memiliki direktori root ukuran tetap), hanya saja ia membutuhkan skenario patologis seseorang yang banyak merusak sistem file dan tidak pernah menarik file dan direktori yang dipulihkan. keluar dari direktori pemulihan.

( fsck menggunakan subdirektori tunggal tetap karena banyak format sistem file Unix memiliki tabel inode ukuran tetap. Sebaliknya, HPFS dan NTFS tidak memiliki tabel ukuran tetap untuk menyimpan f-node dan entri MFT, dan FAT bahkan tidak memiliki hal-hal seperti itu di tempat pertama. Ketika seseorang memiliki tabel ukuran tetap, seseorang berpotensi dapat menghantam situasi di mana tidak ada i-node gratis yang tersedia untuk digunakan sebagai subdirektori pemulihan baru tetapi satu memiliki i-node yatim untuk dipulihkan. fsck menghindari kebuntuan ini dengan mengharuskan, untuk operasi yang tepat, yang dibuat oleh administrator sistem lost+found sebelumnya, dan hanya pernah menggunakan direktori yang sama setiap kali. Tentu saja, itu akan membuat lost+found jika tidak ada, tetapi itu membuka pintu untuk terjadinya kebuntuan yang disebutkan sebelumnya.)

Banyak "perintah DOS menjelaskan" situs WWW tidak akan memberi tahu Anda tentang ini chkdsk, meskipun telah bekerja seperti ini pada sistem operasi yang Anda dan kebanyakan orang miliki selama dua dekade. Mereka malah akan tetap memberi tahu Anda bagaimana MS-DOS lama chkdsk bekerja. OS / 2 versi 1.2 keluar pada tahun 1989. Windows NT, yang versi pertamanya pada tahun 1993, mewarisi beberapa hal dari OS / 2 1.x, termasuk perilaku chkdsk. Sementara itu, dunia DOS dan DOS + Windows berjalan dengan gembira selama dekade berikutnya, tanpa memperhatikan - atau pernah menggabungkan - chkdsk perbaikan dari akhir 1980-an. Dunia DOS dan DOS + Windows, dan semua buku dan situs WWW yang muncul untuk menceritakan bagaimana mereka bekerja, tetap macet pada tahun 1985, secara efektif. Namun, dunia DOS dan DOS + Windows akhirnya mati karena kematiannya, Windows NT bukan DOS, dan tidak pernah, dan chkdsk perintah di Windows NT berhenti sama dengan DOS chkdsk komando di akhir 1980-an. Perilaku perintah bukanlah perilaku yang orang-orang yang keliru berpikir bahwa itu adalah "perintah DOS" akan memberi tahu Anda.

Dasar pemikiran dan operasi

Salah satu alasannya fsck beroperasi seperti yang dilakukannya adalah dirancang untuk sistem operasi sudah multi-pengguna pada 1980-an. Pada sistem operasi multi-pengguna yang aman, ini merupakan masalah keamanan jika memulihkan file setelah kerusakan disk berarti bahwa setiap orang dapat mengaksesnya di tempat yang sebelumnya tidak dapat diakses. Anda akan menemukan bahwa izin standar untuk lost+found pada sistem Unix atau Linux dengan demikian 0700 ( rwx------ ) dengan pemilik root. Hanya pengguna super yang dapat mengakses konten direktori. Jadi jika file tersebut tidak ada dalam direktori yang dapat diakses grup / diakses dunia sebelumnya, itu tidak tiba-tiba menjadi dapat diakses oleh orang-orang sebagai akibat dari pemulihan dari korupsi sistem file.

chkdsk pada Windows NT menghadapi masalah yang sama, itulah sebabnya Anda akan menemukan itu found. nnn direktori hanya dapat diakses oleh administrator pada volume NTFS. (Pada volume FAT, tidak ada ACL sistem file, jadi tidak mungkin untuk mengamankan hal-hal seperti ini. Namun, file di lokasi aslinya tidak diamankan antara ; jadi ini bukan memperkenalkan lubang keamanan.) Ini juga mengapa Anda akan menemukan bahwa direktori yang mendasari Recycle Bin pada volume NTFS disusun seperti itu. Menghapus file tidak membuatnya tiba-tiba dapat diakses oleh orang lain yang tidak akan memiliki akses ke mereka di direktori asli mereka.

Ketika datang ke nama-nama di tingkat atas found. nnn direktori:

  • Sesuai sifatnya, file dan direktori yatim yang dipulihkan tidak memiliki nama pada volume FAT. Nama-nama akan berada di entri direktori yang menunjuk ke file, tetapi file / direktori tidak memiliki entri direktori yang menunjuk ke mereka . Inilah sebabnya mengapa FILE nnnn .CHK dan DIR nnnn .CHK nama digunakan. Nama harus ditemukan untuk file dan direktori.
  • Pada volume HPFS, dimungkinkan untuk memulihkan nama file yatim, karena disimpan dalam f-node serta dalam entri direktori yang menunjuk ke f-node. Tetapi Anda masih akan menemukan FILE nnnn .CHK dan DIR nnnn .CHK nama yang digunakan.
  • Pada volume NTFS, biasanya tidak ada file yatim yang dipulihkan dengan cara ini, karena entri MFT berisi nama file / direktori dan nomor entri MFT dari direktori yang aslinya berisi. Jadi pemulihan file dan direktori yang hilang pada NTFS sebenarnya dapat menempatkannya kembali di direktori tempat mereka hilang, dan biasanya (tetapi tidak selalu) bahkan tidak found. nnn direktori sama sekali. (Itu terjadi jika tidak ada direktori yang semula berisi dapat dipulihkan untuk menempatkan file ke, tentu saja.) Inilah sebabnya orang jarang melihat found. nnn direktori pada volume NTFS, dibandingkan dengan volume FAT.

Tentu saja, nama-nama file dan direktori dalam direktori yang dipulihkan akan dipertahankan, karena mereka tidak hilang sejak awal. Mereka, lebih tepatnya, entri direktori dalam direktori yang hilang sendiri. Jadi semuanya di bawah Sebuah DIR nnnn .CHK direktori di tingkat atas akan memiliki nama aslinya.

Pada volume HPFS, file / direktori yang hilang adalah f-node (dialokasikan) yang tidak memiliki entri direktori yang mengarah ke sana. Pada volume NTFS, file / direktori yang hilang adalah entri MFT (dialokasikan) yang tidak memiliki entri direktori yang mengarah padanya. Dalam kedua kasus, seluruh ruang yang dialokasikan untuk file / direktori dicatat dalam entri f-node / MFT, dan setiap konflik dengan bitmap alokasi volume diselesaikan untuk mengalokasikan ruang untuk entri f-node / MFT. Pada FAT, segalanya berbeda. Tidak ada entri f-node, i-node, atau MFT. Satu-satunya cara untuk menemukan file / direktori yang hilang adalah dengan mencari di FAT untuk rantai cluster yang tidak memiliki entri direktori yang menunjuk ke mereka, dan FAT aku s peta alokasi demikian juga . Jadi tidak mungkin untuk mendeteksi perbedaan antara yang benar-benar kalah file / direktori dan fragmen file / direktori yang tidak ditandai sebagai bebas di peta alokasi volume Jadi seringkali pada FAT kita menemukan bahwa file atau direktori yang dipulihkan sebagian file atau direktori. (Ini bukan untuk mengatakan bahwa tidak mungkin untuk mendapatkan file parsial / direktori pada HPFS dan NTFS. Hanya saja keadaan yang diperlukan untuk itu jauh lebih jarang, dan pada NTFS sebagian besar dihindari sepenuhnya oleh metadata journal.)

Sekali lagi, pada HPFS dan NTFS dimungkinkan untuk menentukan dari entri f-node / MFT apakah node / entri yang dipulihkan adalah file atau direktori. Ada bendera di entri f-node / MFT yang mengatakan apa itu. Ini tidak terjadi dengan FAT. Sebagus-bagusnya orang dapat menerapkan heuristik untuk melihat isi dari cluster dan kira apa benda itu awalnya. Jadi terkadang, jika konten terlihat benar, direktori yang hilang dapat dipulihkan sebagai file, dan sebaliknya.

Satu catatan terakhir: Ada jenis ketiga file yang dipulihkan pada volume FAT: EA nnnn .CHK. Ini adalah inovasi OS / 2 1.x lain yang bertahan dalam Windows NT. File-file ini mengandung hilang atribut yang diperluas . Set atribut diperluas disimpan dalam file kontainer khusus ( EA DATA. SF ) pada volume FAT. Jika tidak ada entri direktori yang menunjuk ke set atribut diperluas tertentu, set EA itu dianggap hilang, dan salah satu dipulihkan sebagai EA nnnn .CHK file atau hanya ditandai sebagai ruang kosong.


OP meminta informasi tentang bagaimana untuk menghapusnya - apakah Anda salah mengerti pertanyaannya?
Sathyajith Bhat

Tidak, tetapi Anda pasti memilikinya. Bacalah dengan seksama. Si penanya tidak hanya bertanya, "Apa itu?" juga, tetapi menanyakan itu pertama . Jawaban di atas baik itu dan bagaimana cara menghapusnya, meskipun yang kedua berbeda untuk "gunakan saja rd perintah ". Tapi itu karena itu memberikan informasi untuk Mengapa pengguna sewenang-wenang tidak dapat menghapus direktori dan mengapa itu karena desain, dan memang mengapa orang mungkin mau lihat di direktori terlebih dahulu . Ingat mandat kami untuk memberikan penjelasan kepada orang lain, bukan hanya resep mentah untuk robot.
JdeBP

Apa yang memutuskan apakah atribut diperluas dipulihkan atau dibuang?
Daniel Beck

Pada OS / 2 itu adalah pengguna menjawab ya atau tidak untuk pertanyaan di SYS1315 pesan itu CHKDSK meminta xem dengan. ☺
JdeBP
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.