[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Deletion of files from usb-key



I have a SamDisk USB-key filled with photos (.png) which I used for a 
slide show. I now would like to delete them, but whenever the device
is rebooted, the files reappear.

	$ ls -la /media/usb-key
	rwxr-xr-x  file.png /brownh/brownh
	...

Although the files are readable, I find that chown can't change them:  

	# chown brownh:brownh <filename>
	chown: cannot access '<filename>': No such file or directory 
	failed to change ownership of `filename*' to brownh:brownh	

I also find that I can't change permissions. At present are:
	
	xwxr-xr-x  brownh/brownh

If I try to remove the files:

	# rm -f /media/usb-key/*.*

The files disappear. The ls command shows nothing.

However, if I unmount and remount, the files are back (and shown in
green in xterm, which is not normal).

Also, if I chanmge filenames and extensions for the files, when I
reboot, the original name and extension reappears.

In desperation I try:

	$ shred -fuv /media/usb-key *.*
	shred: /media/usb-key/<filename>: pass 1/25 (random)...
	shred: /media/usb-key/<filename> : fdatasync failed: 
		Input/output error
	shred: /media/usb-key/<filename>: pass 2/25 (888888)...
	shred: /media/usb-key/<filename>: fdatasync failed: 
		Input/output error
	...

and also tried: 

	# mformat -v /dev/sdd1

It failed to run, perhaps because the usb-key has no unix low-level 
format. And I also tried:
	
        # fdisk /dev/sdd1 

I print the partition table:

	Disk /dev/sdd1: 512 MB, 512443392 bytes
	16 heads, 62 sectors/track, 1008 cylinders
	Units = cylinders of 992 * 512 = 507904 bytes

	     Device Boot      Start         End      Blocks   Id  System

This suggests there is no partition at present. So I add a partition
(primary, number 1, cylinders 1-1088. Now I print this and have:

	Disk /dev/sdd1: 512 MB, 512443392 bytes
	16 heads, 62 sectors/track, 1008 cylinders
	Units = cylinders of 992 * 512 = 507904 bytes

	     Device Boot      Start         End      Blocks   Id  System
	/dev/sdd1p1               1        1008      499937   83  Linux

And I change the type to 4 and print again:

	Disk /dev/sdd1: 512 MB, 512443392 bytes
	16 heads, 62 sectors/track, 1008 cylinders
	Units = cylinders of 992 * 512 = 507904 bytes

        Device Boot   Start     End   Blocks   Id  System
	/dev/sdd1p1       1    1008   499937    4  FAT16 <32M

And write and quit (w command):

	The partition table has been altered!

	Calling ioctl() to re-read partition table.

	WARNING: Re-reading the partition table failed with error 22:  
		Invalid argument.
	The kernel still uses the old table.
	The new table will be used at the next reboot.

	WARNING: If you have created or modified any DOS 6.x
	partitions, please see the fdisk manual page for additional
	information.
	Syncing disks.

Well, I tried: 

        # sfdisk /dev/sdd1
        Checking that no-one is using this disk right now ...
        BLKRRPART: Invalid argument
        OK
        Warning: start=62 - this looks like a partition rather than
        the entire disk. Using fdisk on it is probably meaningless.
        [Use the --force option if you really want this]

When I use sfdisk with --force option, 

        ...
        Disk /dev/sdd1: 1008 cylinders, 16 heads, 62 sectors/track
        Old situation:
        Units = cylinders of 507904 bytes, blocks of 1024 bytes,
        counting from 0 

           Device Boot Start     End   #cyls    #blocks   Id  System
        /dev/sdd1p1          0       -       0          0    0  Empty
        /dev/sdd1p2          0       -       0          0    0  Empty
        /dev/sdd1p3          0       -       0          0    0  Empty
        /dev/sdd1p4          0       -       0          0    0  Empty

        /dev/sdd1p1 :

Next I try:

	# mkfs.vfat -F 32 /dev/sdd1 
	mkfs.vfat 2.11 (12 Mar 2005)

But my files still there. Fsck didn't help.

My guess is that I need a low level format, but I have no idea how to
do that for a usb-key. Is it usually done with a proprietary low-level
format utility?

 
 
       Haines Brown, KB1GRM

	 
        



Reply to: