fdisk /dev/sdb
Delete partition d 1
Create a new primary partition n p 1
Write to table and quit w q
Then make a FAT32 filesystem mkfs.vfat -F 32 /dev/sdb1
But I guess it is better to use ntfs.
TestDisk: Flash Drive="CHS and LBA don't match" [SOLVED]
linuxcbon:
Here's what I did:
1.
Does that look OK?
Should I have included spaces between n p 1 etc?
GParted shows no change to sdb1; partition still has "unknown" filesystem.
Here's what I did:
1.
Code: Select all
# fdisk /dev/sdb
Command (m for help): d1
Selected partition 1
Command (m for help): np1
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-1974270, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-1974270, default 1974270):
Using default value 1974270
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
# mkfs.vfat -F 32 /dev/sdb1
mkfs.vfat 3.0.11 (24 Dec 2010)
# Should I have included spaces between n p 1 etc?
GParted shows no change to sdb1; partition still has "unknown" filesystem.
linuxcbon, you seem to be leading him down the saem (wrong) path as before. fdisk will, by default, create a type 83 partition -he shouldn't then format it as a FAT if the partition type is not right! And, I thought the whole point here was to create an ext2 FS -or have I missed some important posting?
Sylvander, the fdisk commands seems to have succeeded. All you need to do then is use mke2fs or mkfs.ext2 to format the partition (as ext2). You'll then want to run 'fsck -cp /dev/sdb1' to handle the bad blocks.
Don't use gparted as it seems to not work -as it is prone to do...
If you now want the partition as a FAT, please say so. As for ntfs, there is no way to format a partition as NTFS under linux. If that is what you want, then say so -as you will need to *change* the partition type before using windows to format the partition. windows will not recognize partitions of any non-windows type.
Sylvander, the fdisk commands seems to have succeeded. All you need to do then is use mke2fs or mkfs.ext2 to format the partition (as ext2). You'll then want to run 'fsck -cp /dev/sdb1' to handle the bad blocks.
Don't use gparted as it seems to not work -as it is prone to do...
If you now want the partition as a FAT, please say so. As for ntfs, there is no way to format a partition as NTFS under linux. If that is what you want, then say so -as you will need to *change* the partition type before using windows to format the partition. windows will not recognize partitions of any non-windows type.
At the moment I'll take any filesystem I can get...
Though I'd prefer FAT32.
amigo:
1. Tried this:
[Didn't know what to do with mke2fs, so used mkfs.ext2 instead]
linuxcbon:
2. Last 10 lines of dmesg:
Though I'd prefer FAT32.
amigo:
1. Tried this:
[Didn't know what to do with mke2fs, so used mkfs.ext2 instead]
Code: Select all
# fdisk /dev/sdb
Command (m for help): m
Command action
a toggle a bootable flag
b edit bsd disklabel
c toggle the dos compatibility flag
d delete a partition
l list known partition types
m print this menu
n add a new partition
o create a new empty DOS partition table
p print the partition table
q quit without saving changes
s create a new empty Sun disklabel
t change a partition's system id
u change display/entry units
v verify the partition table
w write table to disk and exit
x extra functionality (experts only)
Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-1974270, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-1974270, default 1974270):
Using default value 1974270
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
# mke2fs
Usage: mke2fs [-c|-l filename] [-b block-size] [-f fragment-size]
[-i bytes-per-inode] [-I inode-size] [-J journal-options]
[-G meta group size] [-N number-of-inodes]
[-m reserved-blocks-percentage] [-o creator-os]
[-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
[-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
[-T fs-type] [-U UUID] [-jnqvFKSV] device [blocks-count]
# mkfs.ext2 /dev/sdb1
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
61568 inodes, 246272 blocks
12313 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=255852544
8 block groups
32768 blocks per group, 32768 fragments per group
7696 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 38 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
# fsck -cp /dev/sdb1
fsck from util-linux 2.19
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb1
/dev/sdb1:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
# 2. Last 10 lines of dmesg:
Code: Select all
[ 1183.901557] sd 4:0:0:0: [sdb] Sense Key : Not Ready [current]
[ 1183.901561] sd 4:0:0:0: [sdb] Add. Sense: Medium not present
[ 1183.901565] sd 4:0:0:0: [sdb] CDB: Write(10): 2a 00 00 00 08 00 00 00 08 00
[ 1183.901572] end_request: I/O error, dev sdb, sector 2048
[ 1238.334837] sd 4:0:0:0: [sdb] 1974271 512-byte logical blocks: (1.01 GB/963 MiB)
[ 1238.335828] sd 4:0:0:0: [sdb] Asking for cache data failed
[ 1238.335830] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 1238.337451] sd 4:0:0:0: [sdb] Asking for cache data failed
[ 1238.337454] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 1238.339085] sdb: sdb1
# Really strange that everything seems to succeed until you run fsck... If you can't mount that now, then it is truly trashed. Just for future reference, you said you'd like a FAT filesystem, but then you used mkfs.ext2 to format it. For a FAT, NTFS or other windows filesystem, while running fdisk, use the '-t' option to change the partition type (called 'system id' in the options). You need to do this before trying to format the drive. As I mentioned, if you wanted an NTFS file system, then you'd need to change the partition type (system id) to one of the valid windows types and then use windows to create the filesystem. But, as of now, I'm convinced your drive is trashed.
Neither fdisk nor dd automatically verify their writes.
You can get dd to write to a rock if it believes that it you have write permission to do so. That doesn't mean that anything actually got written to the rock.
Sylvander has a type b FAT32 partition on his flash drive. He has made many good attempts to change the partition table, and has provided the results of his sessions in fdisk so we can see what he has done.
Yes, he can change the partition type or even delete it in the partition table that fdisk holds in memory. And the p command will show that change. And he uses the w command to write the partition table to the drive, and that completes with no error message.
But the table does not get written.
Currently the drive appears to be unwritable, perhaps permanently so. There is a chance that a low level format will restore it, but unfortunately the utility I found doesn't work for him.
You can get dd to write to a rock if it believes that it you have write permission to do so. That doesn't mean that anything actually got written to the rock.
Sylvander has a type b FAT32 partition on his flash drive. He has made many good attempts to change the partition table, and has provided the results of his sessions in fdisk so we can see what he has done.
Yes, he can change the partition type or even delete it in the partition table that fdisk holds in memory. And the p command will show that change. And he uses the w command to write the partition table to the drive, and that completes with no error message.
But the table does not get written.
Currently the drive appears to be unwritable, perhaps permanently so. There is a chance that a low level format will restore it, but unfortunately the utility I found doesn't work for him.
npierce:
1. "You can get dd to write to a rock if it believes that it you have write permission to do so. That doesn't mean that anything actually got written to the rock"
I think you're correct in saying that.
2. "he uses the w command to write the partition table to the drive, and that completes with no error message"
But, but, but....
When I enter the write command [w], the command console CLOSES!
So I think it likely the changes were NOT written to the drive [because it's READ-ONLY!]
3. "...the table does not get written.
Currently the drive appears to be unwritable..."
Seems so to me.
4. "There is a chance that a low level format will restore it, but unfortunately the utility I found doesn't work for him"
Sad, but true.
amigo:
5. "It is also possible that rebooting after writing the partition table may help -sometimes changing the partition type doesn't take effect until after a reboot"
I had tried that previously, and it failed...
Probably because the drive cannot be written to [for some reason as yet unproved?]
I've seen at least 1 program report that the drive is read-only.
-------------------------------------------
6. I certainly find this problem very interesting.
I'd love to understand what is really amiss with the drive.
i.e. Why is it unwritable=read-only?
1. "You can get dd to write to a rock if it believes that it you have write permission to do so. That doesn't mean that anything actually got written to the rock"
I think you're correct in saying that.
2. "he uses the w command to write the partition table to the drive, and that completes with no error message"
But, but, but....
When I enter the write command [w], the command console CLOSES!
So I think it likely the changes were NOT written to the drive [because it's READ-ONLY!]
3. "...the table does not get written.
Currently the drive appears to be unwritable..."
Seems so to me.
4. "There is a chance that a low level format will restore it, but unfortunately the utility I found doesn't work for him"
Sad, but true.
amigo:
5. "It is also possible that rebooting after writing the partition table may help -sometimes changing the partition type doesn't take effect until after a reboot"
I had tried that previously, and it failed...
Probably because the drive cannot be written to [for some reason as yet unproved?]
I've seen at least 1 program report that the drive is read-only.
-------------------------------------------
6. I certainly find this problem very interesting.
I'd love to understand what is really amiss with the drive.
i.e. Why is it unwritable=read-only?
-
sheldonisaac
- Posts: 902
- Joined: Mon 22 Jun 2009, 01:36
- Location: Philadelphia, PA
the unwriteable flash drive
I guess this won't help, Sylvander; you probably did all tnis,Sylvander wrote: I'd love to understand what is really amiss with the drive.
i.e. Why is it unwritable=read-only?
and seem to find there's something wrong with your thumb drive?
I have a 512MB SD card Kingston. Sliding lock set to locked. in a USB card reader. Lucid Puppy Linux 5.2.8-005
Code: Select all
~> cp sylpheed.desktop~ /mnt/sdb1/
cp: cannot create regular file `/mnt/sdb1/sylpheed.desktop~': Read-only file system
Code: Select all
~> cp sylpheed.desktop~ /mnt/sdb1/
~>
~> ls -lat /mnt/sdb1/
total 32
drwxr-xr-x 2 root root 16384 2013-03-17 13:43 .
-rwxr-xr-x 1 root root 456 2013-03-17 13:43 sylpheed.desktop~
drwxr-xr-x 15 root root 140 2013-03-17 13:40 ..
~>
~> umount /mnt/sdb1
~>
~> fdisk /dev/sdb
The number of cylinders for this disk is set to 3908.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/sdb: 512 MB, 512229376 bytes
8 heads, 32 sectors/track, 3908 cylinders
Units = cylinders of 256 * 512 = 131072 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 3908 500203+ 6 FAT16
Command (m for help): d
Selected partition 1
Command (m for help): p
Disk /dev/sdb: 512 MB, 512229376 bytes
8 heads, 32 sectors/track, 3908 cylinders
Units = cylinders of 256 * 512 = 131072 bytes
Device Boot Start End Blocks Id System
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
~> fdisk /dev/sdb
Command (m for help): p
Disk /dev/sdb: 512 MB, 512229376 bytes
16 heads, 62 sectors/track, 1008 cylinders
Units = cylinders of 992 * 512 = 507904 bytes
Device Boot Start End Blocks Id System
Command (m for help): q
~>
~> dd if=/dev/zero of=/dev/sdb bs=512
dd: writing `/dev/sdb': No space left on device
1000449+0 records in
1000448+0 records out
512229376 bytes (512 MB) copied, 314.13 s, 1.6 MB/s
~>
~> fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
Command (m for help): p
Disk /dev/sdb: 512 MB, 512229376 bytes
16 heads, 62 sectors/track, 1008 cylinders
Units = cylinders of 992 * 512 = 507904 bytes
Device Boot Start End Blocks Id System
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1008, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-1008, default 1008):
Using default value 1008
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 0C
Changed system type of partition 1 to c (W95 FAT32 (LBA))
Command (m for help): p
Disk /dev/sdb: 512 MB, 512229376 bytes
16 heads, 62 sectors/track, 1008 cylinders
Units = cylinders of 992 * 512 = 507904 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 1008 499937 c W95 FAT32 (LBA)
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.
~> mkfs.vfat /dev/sdb1
mkfs.vfat 3.0.7 (24 Dec 2009)
~>
Code: Select all
~> fdisk /dev/sdb
Command (m for help): p
Disk /dev/sdb: 512 MB, 512229376 bytes
16 heads, 62 sectors/track, 1008 cylinders
Units = cylinders of 992 * 512 = 507904 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 1008 499937 c W95 FAT32 (LBA)
Command (m for help): q
~> mkdir /mnt/sdb1
~> mount -t vfat /dev/sdb1 /mnt/sdb1
~> cp sylpheed.desktop~ /mnt/sdb1/
~> ls -lta /mnt/sdb1/
total 24
drwxr-xr-x 2 root root 16384 2013-03-17 14:13 .
-rwxr-xr-x 1 root root 456 2013-03-17 14:13 sylpheed.desktop~
drwxr-xr-x 15 root root 140 2013-03-17 14:12 ..
~>Sylvander,
I'm looking to see if I can locate a low level format utility that will work with your drive. Could you plug in your drive and then post the output of this command?
I'm looking to see if I can locate a low level format utility that will work with your drive. Could you plug in your drive and then post the output of this command?
Code: Select all
lsusbCode: Select all
# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024
Bus 001 Device 003: ID 0a16:2004 Trek Technology (S) PTE, Ltd
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 8087:0024
Bus 002 Device 003: ID 1a86:7584 Unknown
Bus 002 Device 004: ID 04d9:1133 Holtek Semiconductor, Inc.
# Hi Sylvander,
First, I am assuming that you had only your troublesome flash drive plugged in when you ran lsusb. (That's what I wanted, but neglected to say so.) Only one was listed, so it looks like that was the case. Correct?
(If that's not the case, then my assumptions below about the identity of your drive may be wrong.)
I was surprised that it was not listed as a Verbatim product, but it appears that Verbatim sometimes sells devices from other manufacturers such as Kingston Technology, and Trek Technology. The "0a16" manufacturer code identifies yours as being from Trek. I've found no information about the "2004" product code.
In order to find a low level format utility that is known to work with your drive, we need to identify the controller chip used. One might hope that this would be an exact science. There are certainly bloggers on the Web that give one the impression that it is. But such is not the case.
Given the vendor and product codes (0a16:2004 for your drive), it would be nice to just plug those numbers into a data base somewhere and find the controller chip that is used in that product.
And there is a database in Russia that does indeed let you plug those numbers in (http://www.flashboot.ru/iflash.html). But in some cases this results in a list of many chips. And in other cases (such as your drive's 0a16:2004), nothing is found.
Apparently manufacturers use various suppliers for the controller chips that are used in a single product. That is not surprising, but it does make it hard to identify the chip using only the vendor and product codes. What is surprising is that a single vendor and product code can result in a list of devices with various memory sizes. I would have thought that a vendor would assign different product codes for drives of different sizes. But perhaps some vendors consider a product to be one product available in different sizes. It is also certainly possible that the database contains a lot of misinformation -- not surprising since at one time the database was open for anyone to add data. And it is also possible that some of the data was reported based on data from counterfeit flash drives, and so that data is not legitimate.
Anyway, searching just on the vendor code "0a16" gave a short list of flash drives described as "Verbatim Store 'n' Go", or "Verbatim Store 'n' Go Mini". So we are getting warm. Most entries indicated that these use the Trek "TD2SMG12L" controller chip.
So, did I find any utility that you might try? Yes.
I had hoped to find a utility that came from a manufacturer's web site, as was the case for the other utility that you tried. But I didn't. I am less likely to trust something downloaded from some file-sharing web site, and am reluctant to even mention any, lest your "Mini-XP" become infested with some virus.
So first I am going to suggest a newer version of the utility that you already tried. I'm not very hopeful that a newer version will work any better for you than the old one did, but I think it would be safer to try that first, since it comes from a manufacturer's web site.
Looking into the binary, I see references to many chips, so apparently this utility is not limited to one type of controller chip (which explains why someone got it to work with a non-Apacer drive). My guess is that when you got the "USB Flash disk not found", it was not because it couldn't see your flash drive, but because it didn't find a flash drive that was supported by the utility. My hope (although it's not much hope) is that support for your drive has been added to the newest version.
A little digging turned up many versions of the utility at the Apacer web site. I'll document the full list here, but I would suggest that you not bother trying any other than the newest one, for which I've added a live link:
http://www.apacer.com/en/support/downlo ... Repair.zip
2004-04-28 225280 bytes HS20_RepairTool/Repair.exe
http://www.apacer.com/en/support/downlo ... pair_2.zip
2005-12-16 208896 bytes 2134repair_v2.3.1/Formatter.exe
http://www.apacer.com/en/support/downlo ... pair_3.zip
2006-07-28 270336 bytes Repair2611/Formatter_2611.exe
http://www.apacer.com/en/support/downlo ... .8.1.1.zip
2007-04-09 233472 bytes Repair_V2.8.1.1/Formatter.exe
http://www.apacer.com/en/support/downlo ... .9.1.1.zip
2008-03-12 503808 bytes Repair_v2.9.1.1.exe
http://www.apacer.com/en/support/downlo ... 9.1.8A.zip
2009-06-12 528384 bytes Repair_v2.9.1.8A/Formatter2.9.1.8A.exe
http://www.apacer.com/en/support/downlo ... .9.1.9.zip
2009-12-18 524288 bytes Repair_v2.9.1.9/Formatter.exe
http://www.apacer.com/en/support/downlo ... 10.1.1.zip
2010-03-29 512000 bytes Repair_v2.10.1.1/Formatter.exe
(These files also live in an alternative directory: http://ap.apacer.com/pub/media/file/downloads/)
Again, the only one worth trying is the newest, v2.10.1.1; if that doesn't support your drive, it is unlikely (though not impossible) that the older ones will.
If that doesn't work, there are a couple of more you can try.
It looks like the best utility for the TD2SMG12L controller chip is this:
http://flashboot.ru/files/public/USBest ... 0.2.19.rar
2008-12-04 6029380 bytes Super Stick Recovery Tool V1.0.2.19.exe
(If your "Mini-XP" doesn't support .rar files, and your Puppy doesn't already have the unrar utility (i.e., the unrar command says, "bash: unrar: command not found"), you will also need to get that utility, which is available on the forum here: http://www.murga-linux.com/puppy/viewto ... 167#655167)
Again, I am reluctant to suggest files from unknown web sites, but at least flashboot.ru is not just a file sharing web site, and looks fairly legitimate to me. This is the same site that has the database used earlier for looking up the flash drive controller chip. They also have a copy of the Repair_v2.9.1.1.exe file that you downloaded from the Apacer web site. I checked and verified that the one from flashboot.ru is exactly the same as the one from apacer.com, which gives me hope that nothing nasty has been added to their files. (Of course, I can make no guarantees.)
If you choose to try it, you'll need to run it in your "Mini-XP".
If your "Mini-XP" doesn't support .rar files, you can use Puppy to extract the executable like so:
1. Download the file to your /root/ directory.
2. Run these commands:
(Naturally, you then need to move the executable to a place where "Mini-XP" can find it.)
If this utility doesn't help, I know of one more you could try, but will wait 'till we see how this one did before I post that.
Again, I hasten to point out that I have no experience with this utility. I only know that others claimed to have used it successfully with a flash drive containing a Trek TD2SMG12L controller chip.
And I don't even know for sure if your drive has a TD2SMG12L controller chip, since I found no information on your product code (PID) "2004". I only know that all the "Verbatim Store 'n' Go" drives listed with your vendor code (VID) "0a16" used that controller chip, so maybe yours does as well.
So again I remind you that it is possible that the use of this utility could damage your flash drive beyond repair. But since you have already tried the other utility despite a similar warning, I'm guessing you have decided that you will be no worse off than you already are if it does.
And, as we all know, it is certainly possible that we are beating a dead horse. Your drive may have been ready to send to the knackers weeks ago. I only keep making suggestions because I admire your determination to exhaust all possibilities before doing so.
Good luck.
First, I am assuming that you had only your troublesome flash drive plugged in when you ran lsusb. (That's what I wanted, but neglected to say so.) Only one was listed, so it looks like that was the case. Correct?
(If that's not the case, then my assumptions below about the identity of your drive may be wrong.)
I was surprised that it was not listed as a Verbatim product, but it appears that Verbatim sometimes sells devices from other manufacturers such as Kingston Technology, and Trek Technology. The "0a16" manufacturer code identifies yours as being from Trek. I've found no information about the "2004" product code.
In order to find a low level format utility that is known to work with your drive, we need to identify the controller chip used. One might hope that this would be an exact science. There are certainly bloggers on the Web that give one the impression that it is. But such is not the case.
Given the vendor and product codes (0a16:2004 for your drive), it would be nice to just plug those numbers into a data base somewhere and find the controller chip that is used in that product.
And there is a database in Russia that does indeed let you plug those numbers in (http://www.flashboot.ru/iflash.html). But in some cases this results in a list of many chips. And in other cases (such as your drive's 0a16:2004), nothing is found.
Apparently manufacturers use various suppliers for the controller chips that are used in a single product. That is not surprising, but it does make it hard to identify the chip using only the vendor and product codes. What is surprising is that a single vendor and product code can result in a list of devices with various memory sizes. I would have thought that a vendor would assign different product codes for drives of different sizes. But perhaps some vendors consider a product to be one product available in different sizes. It is also certainly possible that the database contains a lot of misinformation -- not surprising since at one time the database was open for anyone to add data. And it is also possible that some of the data was reported based on data from counterfeit flash drives, and so that data is not legitimate.
Anyway, searching just on the vendor code "0a16" gave a short list of flash drives described as "Verbatim Store 'n' Go", or "Verbatim Store 'n' Go Mini". So we are getting warm. Most entries indicated that these use the Trek "TD2SMG12L" controller chip.
So, did I find any utility that you might try? Yes.
I had hoped to find a utility that came from a manufacturer's web site, as was the case for the other utility that you tried. But I didn't. I am less likely to trust something downloaded from some file-sharing web site, and am reluctant to even mention any, lest your "Mini-XP" become infested with some virus.
So first I am going to suggest a newer version of the utility that you already tried. I'm not very hopeful that a newer version will work any better for you than the old one did, but I think it would be safer to try that first, since it comes from a manufacturer's web site.
Looking into the binary, I see references to many chips, so apparently this utility is not limited to one type of controller chip (which explains why someone got it to work with a non-Apacer drive). My guess is that when you got the "USB Flash disk not found", it was not because it couldn't see your flash drive, but because it didn't find a flash drive that was supported by the utility. My hope (although it's not much hope) is that support for your drive has been added to the newest version.
A little digging turned up many versions of the utility at the Apacer web site. I'll document the full list here, but I would suggest that you not bother trying any other than the newest one, for which I've added a live link:
http://www.apacer.com/en/support/downlo ... Repair.zip
2004-04-28 225280 bytes HS20_RepairTool/Repair.exe
http://www.apacer.com/en/support/downlo ... pair_2.zip
2005-12-16 208896 bytes 2134repair_v2.3.1/Formatter.exe
http://www.apacer.com/en/support/downlo ... pair_3.zip
2006-07-28 270336 bytes Repair2611/Formatter_2611.exe
http://www.apacer.com/en/support/downlo ... .8.1.1.zip
2007-04-09 233472 bytes Repair_V2.8.1.1/Formatter.exe
http://www.apacer.com/en/support/downlo ... .9.1.1.zip
2008-03-12 503808 bytes Repair_v2.9.1.1.exe
http://www.apacer.com/en/support/downlo ... 9.1.8A.zip
2009-06-12 528384 bytes Repair_v2.9.1.8A/Formatter2.9.1.8A.exe
http://www.apacer.com/en/support/downlo ... .9.1.9.zip
2009-12-18 524288 bytes Repair_v2.9.1.9/Formatter.exe
http://www.apacer.com/en/support/downlo ... 10.1.1.zip
2010-03-29 512000 bytes Repair_v2.10.1.1/Formatter.exe
(These files also live in an alternative directory: http://ap.apacer.com/pub/media/file/downloads/)
Again, the only one worth trying is the newest, v2.10.1.1; if that doesn't support your drive, it is unlikely (though not impossible) that the older ones will.
If that doesn't work, there are a couple of more you can try.
It looks like the best utility for the TD2SMG12L controller chip is this:
http://flashboot.ru/files/public/USBest ... 0.2.19.rar
2008-12-04 6029380 bytes Super Stick Recovery Tool V1.0.2.19.exe
(If your "Mini-XP" doesn't support .rar files, and your Puppy doesn't already have the unrar utility (i.e., the unrar command says, "bash: unrar: command not found"), you will also need to get that utility, which is available on the forum here: http://www.murga-linux.com/puppy/viewto ... 167#655167)
Again, I am reluctant to suggest files from unknown web sites, but at least flashboot.ru is not just a file sharing web site, and looks fairly legitimate to me. This is the same site that has the database used earlier for looking up the flash drive controller chip. They also have a copy of the Repair_v2.9.1.1.exe file that you downloaded from the Apacer web site. I checked and verified that the one from flashboot.ru is exactly the same as the one from apacer.com, which gives me hope that nothing nasty has been added to their files. (Of course, I can make no guarantees.)
If you choose to try it, you'll need to run it in your "Mini-XP".
If your "Mini-XP" doesn't support .rar files, you can use Puppy to extract the executable like so:
1. Download the file to your /root/ directory.
2. Run these commands:
Code: Select all
mkdir /root/supper_stick
cd /root/supper_stick
unrar e /root/Super_Stick_Recovery_Tool_V1.0.2.19.rarIf this utility doesn't help, I know of one more you could try, but will wait 'till we see how this one did before I post that.
Again, I hasten to point out that I have no experience with this utility. I only know that others claimed to have used it successfully with a flash drive containing a Trek TD2SMG12L controller chip.
And I don't even know for sure if your drive has a TD2SMG12L controller chip, since I found no information on your product code (PID) "2004". I only know that all the "Verbatim Store 'n' Go" drives listed with your vendor code (VID) "0a16" used that controller chip, so maybe yours does as well.
So again I remind you that it is possible that the use of this utility could damage your flash drive beyond repair. But since you have already tried the other utility despite a similar warning, I'm guessing you have decided that you will be no worse off than you already are if it does.
And, as we all know, it is certainly possible that we are beating a dead horse. Your drive may have been ready to send to the knackers weeks ago. I only keep making suggestions because I admire your determination to exhaust all possibilities before doing so.
Good luck.