Linux, iHP-140 and mystery files

[spurty]

Hope this wasn't covered but my searching only uncovered something in an unrelated thread about Linux USB drivers not quite being ready for prime time. Anyway, I used to use Rockbox exclusively thru Windows XP and had no problems. The LED light on my player would light when it was transferring and wouldn't let me unmount the player until it was finished doing whatever it was doing.

Now I'm using the latest build with a Puppy Linux live CD and I think it works most of the time but when copying files over the player the indicator light doesn't come on. On a few occasions I think I must have unmounted the player before copy completion because there will be empty or broken files within a directory -- it'll play track 2 then skip to 14 or just get stuck on 3.

I've used several versions of Rockbox in past year or so and have noticed the USB Bootloader screen change a couple of times. Does that vary with operating system and is that what my problem is? Is there a temporary work around like 'ps' to check that the copy process is in fact done? Other than that I'm having to listen to all the files off the player while it's still connected to my computer to make sure they are actually there.

Thanks.

[Chronon]

Have you run a disk checking utility?  If your file system is damaged transferring more files to it isn't a good idea.  You should repair any damage otherwise the situation will likely get worse.

I use my players with Linux and don't have any problems. 

[spurty]

Newbie question: Do most Linux distros come with a basic file system checker and repair command?

[bluebrother]

fsck.vfat

[spurty]

For the benefit of other newbies. I ended up using the command below with Puppy Linux 4.20 where "/dev/sda1" is where my iHP-140 was mounted. To check the 40Gs it took about an hour. Not sure what reclaiming unused clusters is. This mean everything checks out?

#dosfsck -vfat /dev/sda1
dosfsck 3.0.1 (23 Nov 2008)
dosfsck 3.0.1, 23 Nov 2008, FAT32, LFN
Checking we can access the last sector of the filesystem
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
  71:20/00, 72:20/00, 73:20/00, 74:20/00, 75:20/00, 76:20/00, 77:20/00
  , 78:20/00, 79:20/00, 80:20/00, 81:20/00
  Not automatically fixing this.
Boot sector contents:
System ID "MSWIN4.1"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
     32768 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
   4882432 bytes per FAT (= 9536 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 9781248 (sector 19104)
   1220389 data clusters (39989706752 bytes)
63 sectors/track, 255 heads
        63 hidden sectors
  78124032 sectors total
Checking for bad clusters.
Reclaiming unconnected clusters.
Reclaimed 16875 unused clusters (552960000 bytes) in 112 chains.
Checking free cluster summary.
Performing changes.
/dev/sda1: 2503 files, 332279/1220389 clusters

[Chronon]

You need to supply a switch when you call the command in order to have it automatically repair problems.  You should be able to run fsck.vfat --help for further assistance.

[bluebrother]

Not sure what reclaiming unused clusters is. This mean everything checks out?

FAT uses a simply linked lists for files. A big table (the FAT) contains a list of all clusters (the smallest fraction of the filesystem you can allocate). A file is split over several clusters which don't necessarily need to be successive. In the FAT, each cluster is marked as empty, points to the cluster following in the list of a file or is marked as last cluster in a list. This is the data by itself. Now there's the directory entries. Each entry points to the first cluster of that file. To access that file you now know where to start, then you can check the FAT about the next cluster that follows it and so on until you reached the last cluster used by the file.
If you delete a file you have to do two things: you need to remove the entry in the directory, i.e. the pointer to the first cluster. Second, you need to mark all the clusters of a file as empty, so when writing a new file those can get reused.

Due to this structure you can loose clusters by removing the directory entry but not marking the clusters (or only parts of the clusters) in the FAT as empty. If this happened the clusters won't get reused so you can't use the space allocated by those clusters. chkdsk / fsck now checks if all clusters marked as used have a pointer to them. If not, it's a lost cluster. If you create a new directory entry for them (i.e. file pointing to that data) you can delete it and thus regain the space it uses.

(I've left out some details in the explanation, but that's basically what lost clusters are.)

[spurty]

@Chronon
I don't think Puppy has fsck.vfat installed by default. I think Die.net mentioned dosfsck when I searched fsck.vfat. Hope I didn't screw things up. It definitely did something. I thought the -vfat was the switch.
-v
Verbose mode.
-f
Salvage unused cluster chains to files.
-a
Automatically repair the file system.
-t
Mark unreadable clusters as bad.

The files I had on beforehand are still there and play fine as far as I know right now. But now there is a slew of weird FSCK files.

FSCK0000.REC
FSCK0001.REC
...
FSCK0111.REC

And these files actually have varying and substantial sizes. Can I (should I) delete these?

@bluebrother
Thanks for the explanation. Eventually I'd like to build a proper Linux box (Arch I think) and learn some of this stuff properly.

[Chronon]

spurty, Ubuntu seems to consider dosfsck, fsck.vfat and fsck.msdos aliases of each other.  http://manpages.ubuntu.com/manpages/jaunty/man8/dosfsck.8.html

According to bluebrother's explanation, I would guess that those files are references to the aforementioned lost clusters, though I am not totally certain.

[AlexP]

yes, they are recovered "files".  You can safely delete them, unless you want to check them for data you may have lost. 

[spurty]

Wow! This has been an educational thread. The Rockbox community is very welcoming. Thoughtful and patient replies by the extremely knowledgeable developers. Other friendly users who don't know the answer, doing the research and writing back.

Open source development can be tedious and thankless. On the other hand, I am inexpressibly grateful and wish the developers could see the huge smile on my face right now. Music is huge part of my life and RockBox is an amazing tool that makes the experience even better.

[Chronon]

Music is huge part of my life and RockBox is an amazing tool that makes the experience even better.

I will second that!