Secure SDS DATA is fragmented

**RastogiJI** · 22-12-2010

I am using this Dell Dimension E510 from last one year and I am running Windows XP on it. I have installed the PCPITSTOP on this laptop and have used the same for defragmenting my machine. But when I tried doing it in the same way then it gave me an error something like C:\$Secure:$SDS$DATA is fragmented or whatever you guys consider it. Now I have never came across any such error while using PCPITSTOP before.

**Connect_Me** · 22-12-2010

Well, I found it!

Before, NTFS, each file had its security descriptors (right). As there were many files with the same rights, it took a lot of space for nothing. NTFS 5, Microsoft has moved the security descriptors in C: \ $ Secure, which lets you apply a security descriptor to multiple files (and thus save space).

$ Secure contains many things (indexes, data ...)
$ SDS is the area that stock data (security descriptors themselves).

So basically that's part of Windows system files. Now, where it reassures me at least, is that we do not see what's inside, and I wonder if it could not serve as shelters prior to viruses or Trojans. I guess you can ignore the same while defragmenting your machine.

**Bower** · 22-12-2010

Thank God, At last I have got the thread having the same issue as I am getting on my XP machine. I always defragment my machine with O & O Defrag, But it fails to continue defragmentation at 10 or sometimes at 12% with the following.

C: \ $ Secure: $ SDS: $ data
C: \ $ Secure: $ SDH $ INDEX_ALLOCATION
C: \ $ Secure: $ SII: $ INDEX_ALLOCATION
C: \ $ Extend \ $ objid: $ o: $ INDEX_ALLOCATION

**desilva** · 22-12-2010

I don't why your deframenting software shows you problem for defragmenting this part of your windows system files. Never mind here I have posted the real definitions of the those things that you have got in the error:

$ Secure: This metadata file stores a table of security descriptors used by the volume.
$ SDS: This is the named data stream Belonging to $ Secure. See Also $ Secure, Stream.
$ DATA: This attribute contains The actual data for a file. This May Also Have A stream name.

**Wguy2008** · 22-12-2010

I think you should simply not try to defragment this part of your windows system files. Your software must be having some soft feature which intend to leave some directories of folders while defragmenting the data on your windows xp machine. Once you have declared to ignore the same directory where you have got this error message then it should not show you any error while defragmenting next time.

**Visala28** · 22-12-2010

$ MFT, $ Secure, $ SDS, $ DATA and $ BITMAP metafiles are the NTFS file system. You can defragment it, because they are areas within the MFT file. The defragmentation of these files, you can cancel only if you force Windows to create the new MFT or move. The move will only work with FAT volumes that are then converted to NTFS. Rewriting -> see formatting. Just do not trust such Defrag tools. Actually it depends on whether you have an NTFS or FAT32 disks. With FAT32 it first fills the disk with files with "File Fsutil bla.ext <Bytegrosse>" remains free so that at least 12.5% of the remaining space. Then convert the disk to NTFS. When you first create a NTFS partition at the end of the disk with NTFS with at least 12.5% of the total space and format it. Then we enlarged the partition to the beginning of the disk. But as I said, forget this simple defrag tools messages.

**BiGMaCHiNe** · 24-12-2010

I think it depends mainly on the length of the file name and the associated meta information. It certainly is not stored, only the file itself but also all sorts of other stuff. You'd be surprised what there is still so everything. Since the names and metadata can be different sizes, there are behind in deleted files of different size gaps. And if even a large file into a small gap is ... I think you get the idea. The MFT is held at least partly in memory, otherwise the computer would shut grotto. It has to read every file access all related data. Because NTFS stores in a tree, it must walk down each branch of this structure. The more (sub) directories, the more branches and each branch represents a disk access. It would take far too long. In NTFS, there's plenty of RAM used to speed up access, you need to do because of fragmentation does not show any worries. Unless you disturb the 10 ms, it needs to once the building structure in RAM at boot time to sort free of fragments.