I have a Transcend Storejet external USB hard disk. This is not an SSD, but a mechanical disk with rotating plates. I have formatted the whole disk, without partitioning, as NTFS. I have used mkntfs
tool under Linux.
When plugged into a Linux machine, the system sees a drive with two partitions (/dev/sdc
/dev/sdc1
/dev/sdc2
). However, as I know it is a partitionless disk, I can mount the whole device (mount -t ntfs /dev/sdc /mnt
) and it works without any problems.
When plugged into a MS Windows XP machine, the systems sees a disk with two unformatted partitions, and it does not assign a drive letter to either the whole disk, nor to any of the partitions.
Would anyone know how to get MS Windows to mount my disk as a NTFS superfloppy?
I have already tried removing old USB mounting points and residual devices using 'DriveCleanup'. It did not help.
By the way, I also have an external Kingston USB SSD, also formatted as NTFS superfloppy, without partitioning. However, this one is recognized and mounted normally by MS Windows.
Best Answer
I can reproduce your problem and explain it. And fix it, I think.
Short explanation
For some reason the first sector of your disk, when interpreted as MBR, contains semi-valid partition table. Either OS has no reason to assume it is a superfloppy.
Long explanation
MBR vs VBR
Most disks we use have been partitioned. It this case the first 512 bytes of the disk is Master Boot Record (MBR). Even in GUID Partition Table (GPT) the first 512 bytes form some kind of MBR for legacy reasons. The important thing is: every modern OS expects to find MBR at the very beginning of the disk.
Superfloppy is a disk that has been treated as a partition while creating a filesystem. In this case the first 512 bytes contain Volume Boot Record (VBR), like the beginning of a partition would normally do.
Some filesystems utilize VBR to keep their important metadata, NTFS is one of them. Both MBR and VBR can contain bootstrap code. On non-bootable devices this "code" may be trivial, protective or even insane. There is no clear pattern, that's why you cannot tell for sure if your 512-byte sector is MBR or VBR or something else.
In general case the best thing you can do is check if the appropriate fragment looks like a sane MBR partition table. I think this is what operating systems do. Unfortunately it is possible to have a VBR that passes this test.
The problem
Let's compare a basic MBR layout (from here) to NTFS VBR layout (from here):
I took my USB stick and created NTFS superfloppy with
mkntfs -F -f /dev/sdc
. The tool overwrote the whole first sector, including the bootstrap code area. Windows or another OS can assume for a while it's MBR and check its partition table area. This is what it will get:As you can see
fdisk
is able to tell that "this doesn't look like a partition table". Windows will tell basically the same thing, then it will assume the sector is VBR, find NTFS signature in it, finally mount. Indeed ye olde Windows XP had no problem with this. Also my Kubuntu reported indmesg
:but then KDE offered to mount it as superfloppy.
Note that any tool that probes for partition table reads in fact a fragment of bootstrap code from the VBR. This code is not needed for NTFS to work. I checked with
hexdump
that the fragment is not code; it looks like a set of text messages that will be displayed if I try to boot from this device, e.g.:This means I can create a semi-valid partition table and it will only mangle with the text messages which I would probably never see anyway.
Well, I did just that, with
fdisk
I created a partition table that looks valid. Of course it points to "partitions" without filesystems, because the only filesystem is still the NTFS on the superfloppy.In Windows XP the drive behaves almost as your drive. Almost, because I got a letter assigned to the first partition. My real (superfloppy) NTFS filesystem is fresh and empty, yours is not. One of its sectors is interpreted as VBR for the first fake partition. Our sectors surely contain different data, maybe this is the reason. Nevertheless I believe I have just solved your mystery.
It looks as if somebody was about to partition your superfloppy and changed their mind between
fdisk
andmkfs
.The fix
In my case it was enough to write zeros to the partition table:
If I want to restore the whole "bootstrap code" fragment of my superfloppy, I can copy it from another NTFS partition created by
mkntfs
: