I ran chkdsk /f again... from the command prompt.
This is the exact wording.
"Security descriptor verification completed.
The second NTFS boot sector is unwriteable".
NOTE: I question whether that virus was on this drive, I ran the killer
and maliscious program on it. Maybe that contributed to this, but this
drive did give me the same or similar notice some months ago.
I also tried to delete
System Volume Information
and
Recycler
From Linux, abnd it refused to let me do it. (or all of it, because I
think it removed some parts of it). I have done that on other drives
using linux with no problem, but those were Fat32. This was data from
the old system which became infected, so I wanted to get rid of it if
possible. Actually, I would like to entirely avoid having those files
written to removable drives anyhow. But I dont know how.
Someone here, thinks the second NTFS boot sector is near the
end of the partition.
https://forum.acronis.com/forum/6228
And what that suggests to me, is you used Linux to resize
the partition, and the physical and virtual size of the partition
no longer match.
The physical size of the partition, is recorded in the partition table.
The MBR holds the partition information. You can view that with
PTEDIT32 in Window or with sudo fdisk /dev/sda
type of command in Linux.
Now, within the physical disk (say it has a thousand sectors),
some number of clusters are defined. Say a cluster is eight
sectors. A thousand sectors would give me room for 125 clusters.
Now, say I do something dopey. I edit the MBR contents using PTEDIT32
and "make the partition a wee bit shorter". Suddenly, the last
clusters are outside the partition.
If you resize from Linux, it resizes in two stages. The order it
does this, is a function of whether the partition is expanding or contracting.
If you need to contract a partition...
reduce virtual cluster count, move stuff out of the way
now fix up the partition table and total number of LBA sectors
If you need to expand a partition...
set the partition table, so the total number of LBA sectors is larger
increase virtual cluster count, tidy up bookkeeping in file system header
(the first 63 sectors or so perhaps).
Now, I've seen file systems damaged in both Linux and Windows.
One user had a partition, where the physical size was
twice as large as the virtual size. It was like a sloppy
pair of shoes, with a tiny foot inside the shoe. This happened
when using the Disk Management shrink function or something.
Normally, Windows never gives even a whiff or a hint, of the
two aspects of a partition.
Whereas Linux is quite explicit about this. If you use GPARTED
partition manager, and check the log later, you can see the two
steps being done (order depends on expand or contract). If you're
lucky, you might even see when your partition has been ruined
by GPARTED (for that extra comedy effect, knowing instantly
that you're screwed).
Any time you resize something, it helps to have backups. Of
course, if this is simply a backup drive, you could reformat
the partition, and the reformat will properly "expand the foot
to fill the shoe"
So my guess is, the end of the partition is snipped off, or
there is a size mismatch involved. You may be able to list
the particulars for the volume and figure that out (either
using Partition Magic in Windows or GPARTED or similar in
Linux).
*******
As for SVI, make sure it isn't the spaces in the folder name
that is preventing removal. In Linux from command line, it might be
done like this, with double quotes to pass the folder name
as a string.
rm -Rf "System Volume Information"
System Volume Information is used by System Restore and
it might also be used by VSS subsystem. On a modern OS,
it might still be created, even if System Restore is
turned off. *Do not* delete that folder on your C:
operating system disk. For a data only partition,
you might be able to get away with it.
HTH,
Paul
