[benners]

Does anybody know what creates this file , it is a zero byte file in the system volume information folder.

With SP1 I used to turn off the indexing service and System Restore run a cmd file on the next reboot

cmdow @ /HID
for %%i in (C: D: E: F: G: H: I: J: K: L: M: N: O: P: Q: R: S: T: U: V: W: X: Y: Z:) do if exist "%%i\system volume information" cacls "%%i\system volume information" /e /g benners:f
for %%i in (C: D: E: F: G: H: I: J: K: L: M: N: O: P: Q: R: S: T: U: V: W: X: Y: Z:) do if exist "%%i\system volume information" attrib -s -r -h "%%i\system volume information"
for %%i in (C: D: E: F: G: H: I: J: K: L: M: N: O: P: Q: R: S: T: U: V: W: X: Y: Z:) do if exist "%%i\system volume information" rd /s /q "%%i\system volume information"
exit

and the folder were deleted permanately, they are still deleted but return on subsiquent reboots

[swgreed]

benners, on Aug 12 2004, 07:31 PM, said:

they are still deleted but return on subsiquent reboots

nice script...

you mean they keep returning with SP2?

[benners]

Yes they keep returning, something is re-creating the files.

[swgreed]

did you completely disable system restore?

;Disable System Restore
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore]
"DisableSR"=dword:00000001

;Disable System Restore Service
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\srservice]
"Start"=dword:00000004

[benners]

I edit the sr.inf file so it does not get installed, and indexing service is disabled

[swgreed]

I had the opportunity to test it on a NTFS volume today. Unfortunately your script stops with a syntax error (probably because of %%i) so I did it manually. You are right, the "system volume information" folder is getting restored everytime the machine reboots
That sucks...
Although this behaviour does not occur on FAT32 volumes (the folder stays deleted)

[benners]

I have been trying stopping different services to see if they are the culprit but to no avail I have never had the problem with the syntax, attached is the cmd file I use, I have googled but only 1 result.

I will keep searching and if I find anything I will post back here.

You will need to edit the cmd file and put your username instead of benners, you probably new that but just covering all the bases

Attached File(s)

•  delete.cmd (557bytes)
  Number of downloads: 157

[swgreed]

Your cmd-file works very well, I guess it was my fault, since the command prompt converts "%%i" in the batchfile to "%i" and I kept posting "%%i" manually, what gave a syntax error.

so far so good, SVI-Folder still keeps coming back.

Some sites recommend to delete the SVI-Folder via "rd" (if the user scrambled the system somehow) since it will be recovered on the next reboot

[benners]

I think it has something to do with Dynamic disks, found some info here, win2k related, but it must be something new to service pack 2 as it worked fine in sp1.
I have disabled the Logical Disc Manager but that had no effect, the quest continues

[Kishiro]

@Benners

Did you figure anything out ?
I've tried myself to solve this puzzle, but I can't seem to figure out which process is making the MountPointManagerRemoteDatabase files. The information on the net seems to be rather sparse. However during my testing I've discovered that the files aren't really used or written to. I've disabled System Restore, The Indexing Service and The Distributed Link Tracking Service. If i delete the "System Volume information" folders, they're recreated at startup. If I create the MountPointManagerRemoteDatabase file myself, clear the archive attribute and notes down the timestamp, restarts the machine, I can see that the timestamp has not been changed and the archive-bit is still off, hence no writing to the file. So some process is checking if the file exists, if i dosen't it's recreated, but it seems the file itself is useless.

[visaversa]

@Kishiro

did you tried with regmon and/or filemon from sysinternals? i am pretty sure tyou could monitor what's the process that recreate these files

[benners]

@Kishiro
I have still not made any progress , I think the file is linked to Dynamic disks so in theory it should only be written to (hence a time stamp change) if you have changed your drives to dynamic. I don't understand why it needs to be created if the drives are normal, or, why it is only in SP2, as dynamics disks have been around since Win2k (I think)

[tomcat78]

Hi,

did anyone solve the problem?

I've tried some thing in a VM, but no luck. I've disabled all Services but the dir comes back every restart ;(
If tried to monitor the startup with filemon but no luck. The dir seems to be created bevor the RunOnce from registry.

[Kishiro]

That's the same conclusions I've come to. I've file monitored my machine for 96hours, and the dirs aren't coming back, unless I restart my machine.

It's really annoying, and now it's the only problem I haven't manage to solve in my wonderfull cuztomized unnatended XPSP2 CD.

[swgreed]

same here... I guess we'll have to accept that unless someone hacks some dll-file or find a regkey that supresses that bahaviour

[tomcat78]

I now added Benners Skript to my Autostart

I haven't found anything else.

Greets

[Branstrom]

Someone just HAS to find a fix for this ^_^ It is driving me insane.

[RyanVM]

My bet is that System Volume Information is protected by sfcfiles.dll.

Anyway, why are you so hellbent on deleting a hidden folder with one zero byte file inside it?

[Suave]

The reason we want to get rid of the System Volume Information folder is because it gets in the way of defrags and disk checks, especially on removable drives formatted with NTFS.

But more than that it is the principle of the matter: My hard drive belongs to me, not Microsoft. Sure XP can have C: but the rest of my drives are mine and mine alone. It is an affront that Microsoft think they can hide files on our hard drives and deny us access to them. I will not rest until it is permanently destroyed.

[Tsunami]

I have System Restore disabled, and deleted all files in System Volume Information. It still recreates MountPointManagerRemoteDatabase and tracking.log, but I really can't be bothered that much, since the first file is 0 bytes, and the second is 20 bytes. I'd rather see it gone too, though. I don't understand how it can get in the way with defrags and disk checks if you give everyone full rights to the folder and files.