Deleting Index entry — why so many and what to do? chkdsk question
C:\Documents and Settings\root>chkdsk
The type of the file system is NTFS.
WARNING! F parameter not specified.
Running CHKDSK in read-only mode.
CHKDSK is verifying files (stage 1 of 3).
File verification completed.
CHKDSK is verifying indexes (stage 2 of 3).
Deleting index entry resume.dat in index $I30 of file 48292.
Deleting index entry resume.dat.old in index $I30 of file 48292.
Deleting index entry RESUME
1.OLD in index $I30 of file 48292.
Deleting index entry Dc104.zip in index $I30 of file 61359.
Deleting index entry Dc105.exe in index $I30 of file 61359.
Deleting index entry Dc106.exe in index $I30 of file 61359.
Deleting index entry Dc107.lnk in index $I30 of file 61359.
Deleting index entry Dc108.zip in index $I30 of file 61359.
Deleting index entry Dc109.lnk in index $I30 of file 61359.
Deleting index entry Dc110.zip in index $I30 of file 61359.
Deleting index entry Dc111.wmv in index $I30 of file 61359.
Deleting index entry Dc112.avi in index $I30 of file 61359.
Deleting index entry Dc96.lnk in index $I30 of file 61359.
Deleting index entry Dc97.lnk in index $I30 of file 61359.
Deleting index entry OIScatalog.cag in index $I30 of file 138813.
Deleting index entry OISCAT
1.CAG in index $I30 of file 138813.
Index verification completed.
Errors found. CHKDSK cannot continue in read-only mode.
C:\Documents and Settings\root>chkdsk /f c:
The type of the file system is NTFS.
Cannot lock current drive.
Chkdsk cannot run because the volume is in use by another
process. Would you like to schedule this volume to be
checked the next time the system restarts? (Y/N) y
This volume will be checked the next time the system restarts.
C:\Documents and Settings\root>
I can run chkdsk /f c: many times and I still get these minor or maybe not so minor errors. One thing I’ve noticed, is that I cannot move a folder nor delete a folder directory as it stops in the middle and tells me that the directory is not empty.
I can do a copy with no errors. I frequently have this across systems in varying degrees. I shudder to think about running a /r as it takes such a long time.
What causes these errors and what can be done to mitigate their occurrence?
Deleting index entry in index i30 что это
—————
Event Type: Error
Event Source: Ntfs
Event Category: Disk
Event ID: 55
Date: 22.10.2007
Time: 10:52:55
User: N/A
Computer: SERVER
Description:
The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume DATA1.
—————
—————
Type: Information
Event Source: Application Popup
Event Category: None
Event ID: 26
Date: 15.10.2007
Time: 17:53:33
User: N/A
Computer: SERVER
Description:
Application popup: Windows — Corrupt File : The file or directory F:\<путь к файлу>\file.xls is corrupt and unreadable. Please run the Chkdsk utility.
—————
—————
chkdsk /f /x
The type of the file system is NTFS.
Cannot lock current drive.
Volume dismounted. All opened handles to this volume are now invalid.
Volume label is OFFICE.
CHKDSK is verifying files (stage 1 of 3).
552400 file records processed.
File verification completed.
25 large file records processed.
0 bad file records processed.
0 EA records processed.
0 reparse records processed.
CHKDSK is verifying indexes (stage 2 of 3).
Deleting an index entry from index $O of file 25.
Deleting an index entry from index $O of file 25.
Deleting an index entry from index $O of file 25.
Deleting an index entry from index $O of file 25.
Deleting an index entry from index $O of file 25.
Deleting an index entry from index $O of file 25.
Deleting an index entry from index $O of file 25.
Deleting an index entry from index $O of file 25.
Deleting an index entry from index $O of file 25.
Deleting an index entry from index $O of file 25.
Deleting an index entry from index $O of file 25.
Deleting an index entry from index $O of file 25.
Deleting index entry dir0001.chk in index $I30 of file 32.
Deleting index entry (-77D8
1 in index $I30 of file 33647.
Deleting index entry __22_1
1.DOC in index $I30 of file 33818.
Deleting index entry CONS#5_333012.USR in index $I30 of file 34458.
Deleting index entry CONS#5
1.USR in index $I30 of file 34458.
Deleting index entry DOCS#DD1009#0000.ANS in index $I30 of file 34458.
Deleting index entry DOCS#D
1.ANS in index $I30 of file 34458.
Deleting index entry POS.rar in index $I30 of file 66735.
Deleting index entry 0019
1.CDR in index $I30 of file 334853.
Deleting index entry 4B0F
1.CDR in index $I30 of file 334853.
Deleting index entry Df22611.CFG in index $I30 of file 461846.
1428034 index entries processed.
Index verification completed.
CHKDSK is recovering lost files.
25 unindexed files processed.
25 unindexed files processed.
CHKDSK is verifying security descriptors (stage 3 of 3).
552400 security descriptors processed.
Security descriptor verification completed.
11035 data files processed.
Correcting errors in the master file table’s (MFT) BITMAP attribute.
CHKDSK discovered free space marked as allocated in the volume bitmap.
Windows has made corrections to the file system.
268430052 KB total disk space.
108550092 KB in 163118 files.
56092 KB in 11040 indexes.
0 KB in bad sectors.
626636 KB in use by the system.
65536 KB occupied by the log file.
159197232 KB available on disk.
4096 bytes in each allocation unit.
67107513 total allocation units on disk.
39799308 allocation units available on disk.
Linux и NTFS: Ошибка ввода/вывода
Опишем окружение в котором возникла ошибка ввода/вывода:
- ОС: Linux совместно с Windows
- HDD: два диска, на одном Windows XP (далее ДИСК 1 ), на другом Linux Debian 7.x (далее ДИСК 2 )
Каждый диск разбит на два раздела, — на диске с Windows XP два раздела с файловой системой NTFS, на втором диске с Linux Debian 7.x один раздел EXT4, на котором и установлен Linux, а на втором собственно NTFS. Окружением для рабочего стола Linux было выбрано Xfce, файловый менеджер по умолчанию Thunar 1.2.3 (Thunar это быстрый и простой в использовании файловый менеджер для рабочего окружения Xfce.), текстовый редактор gedit.
Ошибка ввода/вывода появилась на ДИСК 2 в разделе с файловой системой NTFS, который монтировался вручную после входа в уч. запись Linux.
Когда именно появилась Ошибка ввода/вывода на NTFS разделе сказать сложно, но предположительно после очередного переключения между ОС. На ДИСК 2 были расположены совместно редактируемые файлы, — т.е. эти фалы (Test.txt один из них) были открыты в текстовом редакторе notepad++ под ОС Windows XP и в текстовом редакторе gedit под Linux Debian 7.x. Перед переключением между ОС каждая ОС переводилась в спящий режим с сохранением запущенных программ и открытых файлов.
Иногда выполнялась перезагрузка ОС Linux Debian 7.x, но ОС Windows XP всегда переводилась в спящий режим, при этом после перезагрузки Linux Debian 7.x восстанавливалась сессия запущенных на момент перезагрузки/выключения программ, в том числе и редактора gedit с совместно редактируемым Test.txt . Потому как раздел NTFS с ДИСК 2 монтировался вручную, то после перезагрузки в gedit был открыт Test.txt с сообщением об ошибке доступа, но после ручного монтирования NTFS раздела редактор gedit предлагал обновить файл по причине его изменения.
Не скажу, как и почему стала появляться Ошибка ввода/вывода, — возможно gedit попутал uid/gid (файловые/индексные дескрипторы) и при сохранении в Master File Table (MFT) прописал не то, не тем и не туда, но вот, что получилось после очередного переключения между ОС при совместном редактировании файлов:
Попытка открыть каталог » /media/SATA2/PROFILE/User/Рабочий стол » в Thunar:
Остальное содержимое каталога было не доступно для просмотра/редактирования
Попытка сохранить уже открытый в gedit текстовый файл Test.txt :
При использовании файлового менеджера NAUTILUS удалось открыть каталог /media/SATA2/PROFILE/User/Рабочий стол и удалить » Test.txt «, но вот создать заново Test.txt или создать «Безымянный документ» и переименовать его в «Test.txt» не удалось:
Следующий глюк сопутствовал Ошибкам ввода/вывода, но вот при каких условиях возник не припомню (вероятно при нескольких одновременных попытках монтирования):
Владелец и права на файл Test.txt не известны:
В некоторых манах для лечения предлагалось использовать ntfsfix -b /dev/sdb5 , предварительно отмонтировав его, — но проблема не решилась.
В среде Linux на ДИСК 2 были созданы текстовые файлы » Test_2.txt » и » Test_3.txt » и совершено переключение на Windows XP где эти файлы были не доступны даже для просмотра, хотя после перехода обратно в Linux их можно было просматривать и редактировать.
Проблему с косяком в NTFS разделе на ДИСК 2 удалось решить только с помощью стандартного средства проверки дисков входящего в ОС Windows XP в процессе перезагрузки:
Увидев на экране Deleting index entry . я зразу же понял, что этих файлов нам уже не видать как своих ушей, — разумеется, так и есть.
Вероятно (http://ru.wikipedia.org/wiki/NTFS#Linux) поддержка NTFS в Linux осуществляется при помощи ntfsmount (использующая FUSE), которая позволяет монтировать NTFS-разделы на запись, но с некоторыми ограничениями.
Существует также ещё один способ монтирования NTFS с возможностью чтения/записи, — это Проект NTFS-3G, который по заявлениям является более функциональным и стабильным вариантом (также использующий FUSE) дающий более широкие возможности по созданию/изменению/удалению/перемещению файлов (исключая сжатые и зашифрованные файлы) в файловой системе NTFS. В тоже время тесты показывают, что NTFS-3G не оптимизирован для производительности, а разработчики заявляют, что это связано с обеспечением повышенной надёжности и, что производительность является второстепенной задачей.
Никто не застрахован от возникновения каких-то ошибок на разделах с файловой системой NTFS или же вовсе полного краха таких разделов с необходимостью полного форматирования. Поэтому, при использовании Linux лучше вовсе не использовать NTFS разделов, или же использовать их как можно реже.
Основные причины ошибок ввода/вывода
- Значит это всё масонский заговор дядюшки Билла. На буржуйских веб-ресурсах бродит информация о том, что стандарт NTFS меняется в каждой новой версии Windows, что вполне предсказуемо, включая сервис-паки и промежуточные патчи. При этом, разумеется, изменения не придаются общественной огласке, а следовательно нет возможности в полной мере обеспечить стабильную работу с NTFS в свободных ОС таких как Linux.
- Отмечено также, что на разделах NTFS возможно изменение уже существующих файлов с незначительным изменением их размера, но при создании новых файлов или существенного изменения уже существующих может вызвать проблемы и даже «запороть» весь раздел.
- Проблемы с отображением созданных в Linux на NTFS разделе файлов, а также проблемы с ошибками ввода/вывода, могут возникнуть если на ПК установлено несколько ОС (ака Мультизагрузка, Multi-boot), — Windows vs Linux. Пик ошибок ввода/вывода отмечен когда Windows была переведена в спящий режим, а после очередного включения запущен Linux из-под которого на NTFS разделе создавались/редактировались файлы. Другими словами если мы хотим из-под ОС Linux, в условиях мультизагрузки (Multi-boot), относительно безопасно создавать/редактировать файлы на NTFS разделах совместно используемых обеими ОС, то перед запуском ОС Linux мы должны выполнить полную перезагрузку или остановку ОС Windows, но не в коем случае не переводить Windows в спящий режим!
- SRT-кэширование (Smart Response Technology) — ещё одна «фича», которая может стать причиной невидимости из-под Windows на NTFS разделах файлов, которые создавались в Linux. Предположительно Linux не поддерживает SRT-кэширование (касается только SSD дисков), которое поддерживает Windows, а значит при создании из-под Linux-а файлов на SSD дисках с активным SRT-кэширование кэш не обновляется и после загрузки Windows файлов не обнаруживается. Предлагается отключить SRT-кэширование для SSD диска.
Тема использования NTFS в Linux является довольно актуальной, требует более подробного изучения и дополнительных экспериментов. О появлении новых багов, в ходе использования NTFS разделов в Linux, и, способов их решения, — будем дописывать в этой же статье.
“Deleting index entry” How can i recovery the lost files
Just before reboot, i still use the files as well. After a reboot, my pc check disk, then they delete them. I think "Deleting index entry" only delete index , not data. is It true?
How can i recover them?
I searched the solution, then find folder "found.00X" But i can’t find the lost files.
I used chkdsk /r and got no problem. I also used Recuva which don’t show the lost files.
Any idea?
Any idea to help me recover these files would be appreciated.
I also need to help to prevent "Deleting index entry" loss my files.
Here is the log
USAFRet
Titan
Reputable
I have dual boot Win XP and Win 7.
I work almost on win XP, i use win 7 for gaming only. And sometimes win 7 show chkdsk on startup. Whenever it happens, if it the show "delete index entry" i think i lost files.
Then i find out the solution, i unchecked "Allow indexing service to index this disk for fast files search" and the losing files become "minimum", but It mean i still lost some files.
I think that is the confliction XP and 7 not my driver is bad.
I run yesterday: chkdsk /f and there is no problem.
I checked S.MART, but it show ok.
I tried "Recuva" and Get back my data NTFS, but it can’t show the lostfiles
I think the lost files are in somewhere like "unused partition" Is there any software to search these?
I think the main issue is "the indexing", i think i don’t need it for stable using, do you know how to disable it to prevent the issue?