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):
MBR │ byte offset │ NTFS VBR
│ hex / dec │
───────────┼─────────────┼─────────────
│ 0x000 / 000 │ mainly NTFS
bootstrap │ … │ metadata
code ├─────────────┼─────────────
│ 0x054 / 084 │
│ … │ bootstrap
───────────┼─────────────┤ code
partition │ 0x1BE / 446 │
table │ … │
───────────┼─────────────┼─────────────
0x55 │ 0x1FE / 510 │ 0x55
0xAA │ 0x1FF / 511 │ 0xAA
───────────┴─────────────┴─────────────
I took my USB stick and created an 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:
#fdisk -l /dev/sdc
Disk /dev/sdc: 31.5 GB, 31466323968 bytes
64 heads, 32 sectors/track, 30008 cylinders, total 61457664 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2052474d
This doesn't look like a partition table
Probably you selected the wrong device.
Device Boot Start End Blocks Id System
/dev/sdc1 ? 6579571 1924427647 958924038+ 70 DiskSecure Multi-Boot
/dev/sdc2 ? 1953251627 3771827541 909287957+ 43 Unknown
/dev/sdc3 ? 225735265 225735274 5 72 Unknown
/dev/sdc4 2642411520 2642463409 25945 0 Empty
Partition table entries are not in disk order
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 an NTFS signature in it, finally mount. Indeed ye olde Windows XP had no problem with this. Also my Kubuntu reported in dmesg:
sdc: unknown partition table
but then KDE offered to mount it as a superfloppy.
Note that any tool that probes my USB stick for a partition table reads in fact a fragment of the 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.:
Press Ctrl+Alt+Del to restart
This means I can create a semi-valid partition table and it will only mangle 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 the VBR of 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 and mkfs.
The fix
In my case it was enough to write zeros to the partition table:
dd if=/dev/zero of=/dev/sdc bs=1 seek=446 count=64
If I want to restore the whole "bootstrap code" fragment of my superfloppy, I can copy it from another NTFS partition created by mkntfs:
fallocate -l 2MiB tmp.ntfs
mkntfs -F -f tmp.ntfs
dd if=tmp.ntfs of=/dev/sdc bs=1 skip=84 seek=84 count=426
rm tmp.ntfs
