Jump to content

jmorlan

Members
  • Content Count

    31
  • Joined

  • Last visited

About jmorlan

  • Rank
    Candidate
  1. Well, to be fair, I got better information over at DSLR than I got here and an actual solution to this iSwift problem was first posted by Dexter over there. Here, I got an insistence that there was no problem or that the problem couldn't be reproduced. This has been an extremely frustrating experience over a very long time. I'm not surprised that tempers flared. But there has been good information posted here too, and some particularly well done summary posts in recent weeks that I think were very helpful. The value of a forum is the quality of its contributors and I think there are excellent contributors both here and there. But I agree there have been over-the-top and irrational posts on both sides and in both forums. Par for the course I'd say.
  2. Thank you for the update. However, I think the Knowledge base needs much more. It fails to mention that the NTSF ObjectID remain after KAV has been removed from a system and that CHKDSK issues may persist after KAV is uninstalled. Further it does not offer a method of removing ObjectIDs if/when KAV is removed. And lastly it doesn't admit that ObjecteIDs are added to every new file even when ISwift is turned off.
  3. They have stated that they are working closely with Microsoft on the issue. [Translation: It's a bug in CHKDSK, not our problem.] As if MS is about to release a new version of CHKDSK which will be Kaspersky compatible. Bottom line is take responsibility for your own system. The problem is, was and always will be NTObjectIDs added by iSwift even when iSwift was supposedly disabled. Use the command line FSUTIL routine and clean up your own system if you have a CHKDSK issue caused by iSwift.
  4. All you have to do is paste the command line into notepad, then change the drive letter, then copy the revised version to the clipboard and paste it back into the command prompt. But I don't think you need the drive letter at all. It will just run on the drive or partition from which it is invoked at the command prompt.
  5. Thanks for the link. I would just use the syntax Dexter posted at the above link. I don't think the drive letter is actually needed unless you want to run the routine from a drive other than the one you want to clean. Otherwise it will assume the current drive and directory. Good luck.
  6. Yes, just substitute other drive letters. But in order to work properly, I think you need to run it from the command prompt of the root directory of the drive you want to clean. Otherwise it will only clean the current directory and all sub-directories. You may want to try it on a small directory with a few sub-directories first, before wholesale cleaning an entire drive. Although this routine has worked great for me and others, I make no guarantees that it is safe. I think it's probably safe for most systems, but the MS documentation on FSUTIL warns that changing or deleting ObjectIDs can cause data loss. My understanding is that data loss is likely if you are running a file server on a domain but probably not otherwise. In any event, to play it safe make a backup or image before running this cleanup routine, or wait for an official fix from KAV or MS. However, since KAV has no idea how your system is configured or used, I suspect they are unlikely to fix this issue themselves because of the liability involved if data is lost when the legacy ObjectIDs are removed. That's why I decided to take responsibility for my own system and clean it myself. It was a risk I was willing to take and I am very happy with the results. As always, your mileage may vary.
  7. I finally decided to run the FSUTIL ObjectID removal routine on my entire hard drive. The CHKDSK stage 2 pause is now down to about 20 seconds when it was more like 10 minutes after I scanned my drive with KAV. I feel comfortable that my system is now relatively clean of the legacy KAV/AVS ObjectIDs. For me, this is a far better solution than waiting for MS to release a new version of CHKDSK. Anybody want to take bets on when that will happen? What burns me is that iSwift builds a database that is updated whenever it scans a file and it records the ObjectIDs so that it can skip scanning those files in the future. Why not use that database to remove the ObjectIDs when the program is removed? When I uninstall a program, I'd like to have my files system back to the way it was before. I know that many programs do not behave as well as I would like, but savvy users choose KAV because it's one of the best at detection and disinfection. Those are the kinds of users who want to be informed before irreversible changes are made to their file system. The inability to actually turn of iSwift, even if the user checks the box to do so is just wrong. This is the second time KAV has misunderstood the needs of its customers in exactly the same way. It's iStreams all over again. Same goal, same sort of residual crap left over with obscure consequences not noticed by most, but definitely real issues for some. Anyway, unless you are running a file server on a domain, I think you can safely remove this garbage. At least I did. Here it is again, for those who may have missed it. FOR /R C: %a IN (*.*) DO @ECHO. && @ECHO - %a && @FSUTIL ObjectID Delete "%a" Note: Do not do this if you still have KAV installed or have no bothersome CHKDSK issues. This is only for users who have removed the program and still suffer a stage 2 CHKDSK delay/hang even after the uninstall.
  8. Great! How many files and indexes does CHKDSK report? Is there any noticeable delay at or during Stage 2? I believe the NTSF object identifiers added to every file and left over from iSwift even after KAV is removed are overwhelming CHKDSK in some systems and causing a widely reported delay at or during Stage 2. We are hoping that the iSwift developers will provide a removal tool for the legacy NTSF object identifiers. Thanks.
  9. NTFS also supports removal of NTSF object identifiers when they are no longer needed or used. MS has published code on the subject: http://msdn2.microsoft.com/en-us/library/aa364559.aspx Since some users still experience CHKDSK overload after removing KAV or AVS, and since this symptom disappears when the NTFS object identifiers are removed, why not provide a removal tool for those who are affected. Some people have reported that CHKDSK cannot run to completion which is not a good thing.
  10. Hmmm... I don't think so. After removing KAV/AVS the fidbox.dat and associated files are removed, true. But all the NTSF object identifiers that were added by iSwift are still there after a full uninstallation. These are added to every file on your hard drive after a scan and cannot be removed easily. Dantz has demonstrated that copying the files to another partition and copying them back rids the indexes of these NTSF object identifiers which is expected because copying files removes their uniqueness. But the CHKDSK stage 2 lag which has now been well documented remains after the program is removed. Basically CHKDSK was not designed to expect NTSF object identifiers which are normally used by the Distributed Link Tracking Service to be present on every file on the drive. When there are many files and many indexes, CHKDSK may get overwhelmed on some systems. So, I respectfully disagree that all traces of the iSwift technology are removed after the program is uninstalled. That's why there is now such a fuss about it. An NTSF object identifier removal tool would go a long way to quell the complaints.
  11. Here is a link that explains about NTFS "object identifiers" and how they work. Essentially an attribute is added to each file which uniquely identifies it. http://msdn2.microsoft.com/en-us/library/aa363997.aspx The description explains why copying the files removes the identifiers, but moving them does not. This is exactly the experience described by Dantz above. Here is code which will delete object identifiers: http://msdn2.microsoft.com/en-us/library/aa364559.aspx Will this code also delete the index of all object IDs stored on the volume? If so, then could somebody please write an implementation that we could use to get our file systems back to normal? Please.
  12. Thank for that information. In your case some of the extra data was placed there by IStreams technology which used ADS. Those Alternate Data Streams can be removed using a number of utilities including one supplied directly by Kaspersky as well as the one you used. IStreams has been abandoned by Kaspersky in favor of a new technology called ISwift. Nevertheless, many system which had older versions of KAV may still have the old ADS attached to all their files, even though current versions of KAV no longer use them. It's certainly useful to get rid of them because it's possible that their presence may be aggravating other issues, such as the current CHKDSK problems. The current problem is believed to be caused by extra data added to the indexes by ISwift. This extra data cannot be removed except by extreme measures such as described by Dantz above in this thread. Like ADS, this extra data is not removed by KAV (or AVS) after it is installed. Thus the stall before or during stage two persists after removal of the program. Unfortunately the exact nature and/or format of this extra data (called NTFS-identifiers by KAV) are proprietary. No information or other documentation for these identifiers have ever been published as far as I know. For a description of ISwift technology see: http://www.kaspersky.com/faq?qid=186010624 It appears that it is possible to remove these undocumented NTFS-identifiers using heroic measures like copying an entire drive and copying it back using a utility such as RoboCopy, as demonstrated by Dantz. What needs to be done is for KAV to step up and provide a removal tool for the undocumented NTFS-identifiers placed there by ISwift. I have full confidence that such a removal tool would put our systems back to normal and that the long pauses before or during CHKDSK stage 2 would disappear. Unfortunately KAV continues to stonewall on this issue which is really too bad. It's a great company, but I can no longer recommend it to my clients until they step out in front of this issue and offer a removal tool for the undocumented NTFS identifiers.
  13. Thanks for the suggestion. I downloaded the free Paragon Hard Disk Manager 8 Special Edition and ran the both the MFT and partition defrag. It did not help. There is still a 10 minute delay at stage 2 of CHKDSK. I think we really need some way to get rid of the NTFS-identifiers left by iSwift.
  14. There is some evidence that the CHKDSK issue may only be only apparent with large partitions with lots of files and folders. However some people with large drives and large partitions claim no symptoms. It is unclear whether those people have enabled iSwift, but my recollection is that at least some have. However, I have seen no real data on how this problem effects average users. Many users may have the symptom but never notice it or connect it to KAV. We have seen it reported with KAV6 and with AVS. Symptoms vary from delays during Stage2 to an inability to run CHKDSK to completion. EDIT: Removed questions about the removal tool answered by Lucian Bara while I was posting. Lucian, Is there any chance of getting a removal tool for the left-over NTFS-identifiers?
  15. That's extremely disappointing. In fact Dantz has demonstrated one way of removing the NTFS-identifiers by deleting and restoring data. Another possibility is to convert to Fat32 and back to NTFS using a third party utility. In these cases the indexes will be rebuilt fresh without the NTFS-identifiers placed there by iSwift. Since the iSwift NTFS-identifiers added to the indexes may cause CHKDSK problems for some of us (mine is a 10 minute delay before the start of stage 2), I think Kaspersky should offer a mechanism to undo the damage they have done to the file system. They did the responsible thing and supplied such a tool for iStreams. However the lessons from iStreams do not seem to have been learned. Once you do something to the file system, one cannot foresee all possible consequences in every system. I think it is incumbent on the developers of the iSwift technology to provide a mechanism for removal. Failure to do so is patently irresponsible in my opinion.
×
×
  • Create New...

Important Information

We use cookies to make your experience of our websites better. By using and further navigating this website you accept this. Detailed information about the use of cookies on this website is available by clicking on more information.