Jump to content


  • Content Count

  • Joined

  • Last visited

About Dantz

  • Rank
  1. I would greatly prefer that you retain the thread. Yes, it's a controversial topic, but the heat has finally died down and now we can just be rational about it. Lock it if you must, but please don't remove it. Hopefully it (and the issue) will just fade away . . .
  2. Are you are running ZoneAlarm Antivirus or some other AV that uses the KAV engine? Search for "fidbox.dat". If the file is present and the filedate is current then you probably still have some iSwift-related processes running.
  3. I realize that my comment on locked files sounds kind of strange, and after I wrote it I had to ask myself the same question. I probably should have worded the post differently. I did have a problem with locked files, but I can't remember the details and my notes aren't very good on the ATI tests, as I rejected it fairly quickly for several reasons: 1) Couldn't get it to do what I wanted! 2) Robocopy is a far more capable tool than Acronis True Image for copying and moving files, 3) Robocopy is free. Of course, the downside of using Robocopy was that I had to use either a BartPE or a Windows Vista installation disk in order to copy the OS. That's why I was interested in trying Acronis True Image in the first place - because it creates such a fine little boot disk! I'm sorry I can't answer your question. Maybe if sjokotof would post back here he could tell us how he got it to work, and at that point I will hopefully realize what I did wrong.
  4. You will see several posts by deXter_ on this page, including a description of his fsutil command-line procedure. http://www.dslreports.com/forum/r18608452-...Swift~start=380 Incidentally, deXter_ isn't a regular poster on DSLReports (or at least not under that name). All I know about him is that he posted a nice little command-line procedure, made a few followup posts and then disappeared. His procedure follows, and I suggest you cut and paste. (You can use the mouse to paste into a command line): This will display all of the ObjectIDs in any folder, including subfolders (press Pause if desired, any key to continue, Ctrl+Break to stop): FOR /R %a IN (*.*) DO @ECHO. && @ECHO - %a && @FSUTIL ObjectID Query "%a" This will delete all of the ObjectIDs in any folder, including subfolders: FOR /R %a IN (*.*) DO @ECHO. && @ECHO - %a && @FSUTIL ObjectID Delete "%a" I'm still not convinced of the overall safety of this method, but then again, my method probably isn't safe either and his is a heck of a lot easier. Use at your own risk! After all, there are legitimate uses for ObjectIDs and you will lose those as well. Thus, this procedure should be considered experimental and you should know what you are doing before you try it. I'm guessing that it's fairly safe for a stand-alone computer, but I wouldn't try this on a server. Also, take an image first! It's probably also a good idea to clear all of your existing restore points and set a fresh one (if you normally use System Restore, that is). I haven't yet heard of any serious problems occurring, but Microsoft strongly advises users not to create or delete ObjectIDs and even warns of data loss. Here it is: http://www.microsoft.com/resources/documen...d.mspx?mfr=true You can also use fsutil manually to examine a single file, as follows: fsutil objectid query "filename" (without the quotes) (Replace "query" with "delete" to delete a single ObjectID) Final note: It would be pointless to run deXter_'s procedure if you plan to continue using KAV 7, as it will put all the ObjectIDs right back into your filesystem the next time you scan. Maybe wait for KAV 8?
  5. I'm surprised you got Acronis True Image to work in file copy mode. That was one of the methods I tried and rejected during my early testing. I had trouble with locked files, even when booting from the Rescue CD. Eventually I settled on Robocopy and came up with a complex but effective technique. I was in the process of testing, tweaking, retesting and documenting the whole method and I was just about to post a detailed set of instructions when deXter_ on DSLReports came up with the fsutil procedure, which is far easier than my method.
  6. Very interesting! I very much hope that this new (but similar sounding) technique for v8 will be USER-REMOVABLE, should a user choose to uninstall the program. We don't want to see a repeat of the previous two situations (i.e. alternate data streams, and then ObjectIDs, both of which caused a lot of grief among users who found them difficult to remove).
  7. Personally, I don't view the issue as merely a "chkdsk problem". Rather, I see at as an "ObjectID problem" which sometimes affects the operation of chkdsk, among other things. Delays or failures of chkdsk are merely a symptom, so 'fixing' chkdsk would be more of a band-aid than an actual solution.
  8. Microsoft states that Windows Explorer under Vista has difficulty dealing with large numbers of Extended Attributes. In KAV's case, these EAs are undoubtedly the ObjectIDs that iSwift adds to the NTFS indexes. However, several users have stated that uninstalling KAV solved their problem. This doesn't make sense. The ObjectIDs aren't removed when you uninstall KAV, and thus Explorer should still be erroring out for those users, if Microsoft's explanation is to be believed. Obviously there's something more going on. I think the problem may be caused by a combination of Windows Explorer and a KAV driver. Has anyone tried applying the Microsoft patch to a system that does NOT have Sobko's patch installed? Did it work?
  9. I'm not discussing just the ObjectIDs, I'm referring to the entire iSwift feature. Isn't iSwift at the heart of the current incompatibility with Vista? Doesn't Sobko's patch disable the incompatible portions of an iSwift driver? Personally, I think KAV would be a better product if they completely removed the iSwift code from the program and the drivers and did away with the various iSwift database files (fidbox.idx, fidbox.dat, etc.) iSwift seemed like a good idea at the time, but in retrospect it looks as though the drawbacks are outweighing the benefits.
  10. I'll bet it would also disappear if you removed iSwift and all of its components.
  11. This is just a little bug that slipped past Kaspersky's testing department, and it seems kind of ludicrous to be assigning the blame to Microsoft. You might as well blame the curve that your car was unable to negotiate because you were driving too fast. I wonder how many kids would be able to successfully hand this line to their parents: "I'm sorry I wrecked the car, dad, but it's not my fault. They didn't put enough bank into that curve! I think we should call the highways department and ask them to fix it."
  12. Well, since you went ahead and did it anyway, you are now officially one of our alpha-testers! Please let us know if any glitches develop as you move forward.
  13. This usage of fsutil is still experimental, so I urge caution. It would be much better to try this on a test rig. If you're going to do this to your working PC then you should image your drive and back up your data first. Microsoft has stated that deleting ObjectIDs can cause data loss, among other things. They were referring to Windows Server, but it undoubtedly also applies to XP. Here's a snip from http://technet2.microsoft.com/windowsserve...3.mspx?mfr=true <<Warning Do not delete, set, or otherwise modify an object identifier. Deleting or setting an object identifier can result in the loss of data from portions of a file, up to and including entire volumes of data. In addition you might cause adverse behavior in the Distributed Link Tracking (DLT) Client service and File Replication service (FRS).>>
  14. Thanks for taking an interest. I will reload some of my older images and try to reproduce the chkdsk failures.
  15. There's no easy answer your question, since we don't know any real details about the reasons for the chkdsk symptoms. Kaspersky Labs has provided very little information about the problem, so we have had to rely on a combination of testing and guesswork. They probably know far more than they are letting on, but I suppose it makes much better economic sense for them to keep the issue at a low profile so as not to jeapordize sales. My guess is that most users are blissfully unaware of the whole issue, either because they never run CHKDSK or because they have not yet noticed that CHKDSK now takes a lot longer to run, or even fails to run to completion, since they installed KAV and let it scan their drives. If your only symptom is a noticeable delay at the start of Stage 2, then I think that's a fairly universal experience, and it is probably (I hope) nothing to worry about. Most users who experience the Stage 2 delay have not mentioned any other problems. However, if your symptoms run deeper (i.e. a really long delay, i.e. several minutes or longer, or chkdsk failing to finish and displaying an error message instead), then you have entered the realm of the disaffected who would probably be better off with a different antivirus product. The final decision is up to you, of course. If it helps, here are some of the factors that helped me make mine: 1) KAV, an optional program, appears to negatively affect the operation of CHKDSK, which I consider to be a vital system utility. In most cases it creates a seemingly-harmless delay, but some users (myself included) have experienced worse symptoms. 2) We don't really know why this is happening, and thus we face the obvious questions of whether or not there are any other unexpected but related problems out there that have not yet been recognized. Does this mean that CHKDSK will be less reliable when we truly need it? Are any other programs (defragmenters, etc.) being adversely affected as well? Does it make the NTFS filesystem less stable? We simply don't know. 3) Kaspersky Labs does not appear to be inclined to discuss or even recognize the problem. I consider their lack of forthrightness to be a big turnoff. 4) Uninstalling KAV doesn't solve the problem. The extra information that was added to the indexes will basically be there forever unless you are willing to go to extreme measures to remove it (as I have done). How do you feel about installing a product that can never be fully uninstalled? Personally, I don't like it, and I have to say that KL has lost a lot of my respect for creating such a product, no matter how good their antivirus program may be. 5) For those who choose to uninstall their product, Kaspersky Labs has failed to provide a separate uninstaller that is capable of removing the unwanted index data. I consider this to be another customer service failure on the part of Kaspersky Labs. Apparently they'd rather just keep quiet and hope that it doesn't become an issue, rather than dealing with it. After considering all of this I realized that I would be much happier using a different antivirus product. Incidentally, I came up with a fairly involved technique involving BartPE and Robocopy that can successfully remove the unwanted index-clogging NTFS identifiers, but so far nobody has asked me for the details and so I have not posted them. (Actually, I'm still testing refinements and alternative methods, so when I finally do make that post it will contain a lot more information). Good luck! I hope others will post their opinions and experiences on this thread, but don't expect a definitive answer.
  • 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.