Erasing Index.dat
- Thread starter garrett01
- Start date
No, however the following product can:
Spiderbite http://www.fsm.nl/ward/
Spiderbite http://www.fsm.nl/ward/
eraserbuddy
New Member
I might be totally blind, but I dont see where it says Spiderbite will erase index.dat. I only see that it will extract URLs from it and present them to you.
And how could it be able erase it if eraser cant?
And how could it be able erase it if eraser cant?
1. Spiderbite will remove the records in index.dat.
2.There is an option in eraser to schedule a boot time erase this option will kill the index.dat and most other locked files on reboot.
Unlike spider you will need to hunt out all the directories and index.dats. I note there seems to be several.
Garrett
2.There is an option in eraser to schedule a boot time erase this option will kill the index.dat and most other locked files on reboot.
Unlike spider you will need to hunt out all the directories and index.dats. I note there seems to be several.
Garrett
eraserbuddy
New Member
1. Thanks. I must have missed it. I wonder how it does it.
2. Internet Explorer will create index.dat files for each user on the system. It will also create index.dat files for a system level user (not admin). Im a little fuzzy on this "system level" user, but it generally refers to when IE is called by an app to display a html file. This "system level" IE instance can be a security risk because it runs with its own private set of security settings (not inherited from the user settings). The best way to identify it is that your custom toolbars in IE will not be as you expect.
As for the boot time erase in eraser, I havent played with it much, but I think it was one heck of a great idea to add it. [8D]
2. Internet Explorer will create index.dat files for each user on the system. It will also create index.dat files for a system level user (not admin). Im a little fuzzy on this "system level" user, but it generally refers to when IE is called by an app to display a html file. This "system level" IE instance can be a security risk because it runs with its own private set of security settings (not inherited from the user settings). The best way to identify it is that your custom toolbars in IE will not be as you expect.
As for the boot time erase in eraser, I havent played with it much, but I think it was one heck of a great idea to add it. [8D]
quote:Originally posted by admin
2.There is an option in eraser to schedule a boot time erase this option will kill the index.dat and most other locked files on reboot.
Unlike spider you will need to hunt out all the directories and index.dats. I note there seems to be several.
After our exchange in the other message, I started looking into index.dat. Im hoping Ward will reply to an email I sent him.
It looks like IE6 on XP properly clears the index.dats except for TIF/Content.IE5/index.dat. I realize that clear is different from erase, but its a start.
Without Wards help, I need to figure out where these files are and an easy way to maintain that list.
I have an initial test working (i.e. I can write to the file on startup) in XP.
Dave
2.There is an option in eraser to schedule a boot time erase this option will kill the index.dat and most other locked files on reboot.
Unlike spider you will need to hunt out all the directories and index.dats. I note there seems to be several.
After our exchange in the other message, I started looking into index.dat. Im hoping Ward will reply to an email I sent him.
It looks like IE6 on XP properly clears the index.dats except for TIF/Content.IE5/index.dat. I realize that clear is different from erase, but its a start.
Without Wards help, I need to figure out where these files are and an easy way to maintain that list.
I have an initial test working (i.e. I can write to the file on startup) in XP.
Dave
>>After our exchange in the other message, I started looking into >>index.dat. Im hoping Ward will reply to an email I sent him.
I sent emails last year but got no reply. I suspect he was a student there and has now moved on.
The boot erase I feel is the best option as simply cleaning out entries in index.dat will just leave the data still on the disk requiring a free space wipe.
Garrett
I sent emails last year but got no reply. I suspect he was a student there and has now moved on.
The boot erase I feel is the best option as simply cleaning out entries in index.dat will just leave the data still on the disk requiring a free space wipe.
Garrett
eraserbuddy
New Member
quote:
It looks like IE6 on XP properly clears the index.dats except for TIF/Content.IE5/index.dat. I realize that clear is different from erase, but its a start.
If you cant see them in IE6, they may have been cleared, or they may just be lightly encoded. For example, they could still be there, but just not ascii encoded. Could be something as simple as rot-13 encoded, 7-bit fill-top encoded (random LSB), or the like. Just because they are not obviously visible, doesnt mean they are really gone.
It looks like IE6 on XP properly clears the index.dats except for TIF/Content.IE5/index.dat. I realize that clear is different from erase, but its a start.
If you cant see them in IE6, they may have been cleared, or they may just be lightly encoded. For example, they could still be there, but just not ascii encoded. Could be something as simple as rot-13 encoded, 7-bit fill-top encoded (random LSB), or the like. Just because they are not obviously visible, doesnt mean they are really gone.
quote:Originally posted by eraserbuddy
If you cant see them in IE6, they may have been cleared, or they may just be lightly encoded. For example, they could still be there, but just not ascii encoded. Could be something as simple as rot-13 encoded, 7-bit fill-top encoded (random LSB), or the like. Just because they are not obviously visible, doesnt mean they are really gone.
I examined the files themselves (not that I dont trust what IE is displaying, mind you[
]). The files appear to be used by lots of apps (not just IE). They appear to have a standard 3-part format. The first part looks like a tree, the second is a hash table, and the third is the data, not encrypted. When the files are cleaned by IE, they are reset to an empty state (theres no data, but a repeating pattern). I noticed this in all the versions I found, except the one I noted earlier.
Garrett, I expanded my test to doing a rename() of the files, and that doesnt present a problem to IE, so Erasing them should be fine.
dave
If you cant see them in IE6, they may have been cleared, or they may just be lightly encoded. For example, they could still be there, but just not ascii encoded. Could be something as simple as rot-13 encoded, 7-bit fill-top encoded (random LSB), or the like. Just because they are not obviously visible, doesnt mean they are really gone.
I examined the files themselves (not that I dont trust what IE is displaying, mind you[
]). The files appear to be used by lots of apps (not just IE). They appear to have a standard 3-part format. The first part looks like a tree, the second is a hash table, and the third is the data, not encrypted. When the files are cleaned by IE, they are reset to an empty state (theres no data, but a repeating pattern). I noticed this in all the versions I found, except the one I noted earlier.Garrett, I expanded my test to doing a rename() of the files, and that doesnt present a problem to IE, so Erasing them should be fine.
dave
eraserbuddy
New Member
quote:Originally posted by jsb1
I examined the files themselves (not that I dont trust what IE is displaying, mind you[]). The files appear to be used by lots of apps (not just IE).
AFAIK, they are used by IE, Windows Explorer (the Windows Shell), and anything that relies on the IE rendering engine. Outside of that, I dont know anything that uses them (but I didnt create them, so I might be missing something[
]). Their purpose is pretty simple as far as I know: act as an lookup table to content stored by the now somewhat "integrated" Internet Explorer/Windows Explorer engine.
quote:They appear to have a standard 3-part format. The first part looks like a tree, the second is a hash table, and the third is the data, not encrypted. When the files are cleaned by IE, they are reset to an empty state (theres no data, but a repeating pattern). I noticed this in all the versions I found, except the one I noted earlier.
That seems to be an improvement over previous IE versions which reportedly didnt even "clean" them. Even with this "cleaning" that you are reporting, I still find that the index.dats sometimes get to be huge in size even after you "empty" the cache in IE. It makes little sense to me - when they are "cleaned", they should be reduced to their minimum possible size. My guess is that because Windows Explorer also keeps the index files open that MS may have had experienced troubles in reducing the filesize of index.dat without closing the Windows shell altogether. In other words, IE may not be able to communicate well enough with Windows Explorer (the shell) that it wants to reduce the filesize of an index.dat file. Pure speculation on my part, but its either something like that or sheer stupidity on MSs part.
Long ago, I gave up on trusting MS to handle this sort of thing properly.
quote:Garrett, I expanded my test to doing a rename() of the files, and that doesnt present a problem to IE, so Erasing them should be fine.
Im surprised this works for you. I just went into Windows Explorer and tried to rename an index.dat file. As expected, it told me the file is in use and cannot be renamed. Are you sure you are really renaming a current index.dat, and not one from a directory that is no longer used?
I examined the files themselves (not that I dont trust what IE is displaying, mind you[
]). The files appear to be used by lots of apps (not just IE).AFAIK, they are used by IE, Windows Explorer (the Windows Shell), and anything that relies on the IE rendering engine. Outside of that, I dont know anything that uses them (but I didnt create them, so I might be missing something[
]). Their purpose is pretty simple as far as I know: act as an lookup table to content stored by the now somewhat "integrated" Internet Explorer/Windows Explorer engine.quote:They appear to have a standard 3-part format. The first part looks like a tree, the second is a hash table, and the third is the data, not encrypted. When the files are cleaned by IE, they are reset to an empty state (theres no data, but a repeating pattern). I noticed this in all the versions I found, except the one I noted earlier.
That seems to be an improvement over previous IE versions which reportedly didnt even "clean" them. Even with this "cleaning" that you are reporting, I still find that the index.dats sometimes get to be huge in size even after you "empty" the cache in IE. It makes little sense to me - when they are "cleaned", they should be reduced to their minimum possible size. My guess is that because Windows Explorer also keeps the index files open that MS may have had experienced troubles in reducing the filesize of index.dat without closing the Windows shell altogether. In other words, IE may not be able to communicate well enough with Windows Explorer (the shell) that it wants to reduce the filesize of an index.dat file. Pure speculation on my part, but its either something like that or sheer stupidity on MSs part.
Long ago, I gave up on trusting MS to handle this sort of thing properly.
quote:Garrett, I expanded my test to doing a rename() of the files, and that doesnt present a problem to IE, so Erasing them should be fine.
Im surprised this works for you. I just went into Windows Explorer and tried to rename an index.dat file. As expected, it told me the file is in use and cannot be renamed. Are you sure you are really renaming a current index.dat, and not one from a directory that is no longer used?
Try using RegSeeker, which is freeware from www.hoverdesk.net. With Windows 2000 and IE 6.0, RegSeeker can inspect and remove entries in the index.dat file. You can accomplish this without a reboot, and with IE running. The author does not go into specifics on how he does it, but RegSeeker is a relatively new product and you stand a good chance of contacting him by email.
quote:
quote:Garrett, I expanded my test to doing a rename() of the files, and that doesnt present a problem to IE, so Erasing them should be fine.
Im surprised this works for you. I just went into Windows Explorer and tried to rename an index.dat file. As expected, it told me the file is in use and cannot be renamed. Are you sure you are really renaming a current index.dat, and not one from a directory that is no longer used?
I wrote a program that performs the rename and had it Run from Startup (registry, not folder) during system boot. It renamed index.dat to index.dat.old. IE created a new, initialized index.dat in the same directory.
Dave
quote:Garrett, I expanded my test to doing a rename() of the files, and that doesnt present a problem to IE, so Erasing them should be fine.
Im surprised this works for you. I just went into Windows Explorer and tried to rename an index.dat file. As expected, it told me the file is in use and cannot be renamed. Are you sure you are really renaming a current index.dat, and not one from a directory that is no longer used?
I wrote a program that performs the rename and had it Run from Startup (registry, not folder) during system boot. It renamed index.dat to index.dat.old. IE created a new, initialized index.dat in the same directory.
Dave