I've got a file that when I try to sync it errors out with a permission problem. (0xC004100D is "Permission denied" (Player error)) This results in an inconsistent database error. (I've fsck'ed the drive multiple times, no problems reported.)
When I look at the fid, the song file is fine, but the tags file looks like this:

mataglap:/drive1/fids/_00022# cat 531
ŒŒ.Œö@ Œ Œ.!Œö@@Œ@Œ.AŒö@`Œ`Œ.aŒö@€Œ€Œ.�Œö@ Œ Œ.¡Œö@ÀŒÀŒ.ÁŒö@àŒàŒ.áŒö@��.�ö@ � �.!�ö@@�@�.A�ö@`�`�.a�ö@€�€�.��ö@ � �.¡�ö@À�À�.Á�ö@à�à�.á�ö@ŽŽ.Žö@ Ž Ž.!Žö@@Ž@Ž.AŽö@`Ž`Ž.aŽö@€Ž€Ž.�Žö@ Ž Ž.¡Žö@ÀŽÀŽ.ÁŽö@àŽàŽ.áŽö@��.�ö@ � �.!�ö@@�@�.A�ö@`�`�.a�ö@€�€�.��ö@ � �.¡�ö@À�À�.Á�ö@à�à�.á�ö@
mataglap:/drive1/fids/_00022#

Here's the next song, and in fact the next track from the same album:

mataglap:/drive1/fids/_00022# cat 541
artist=Runrig
bitrate=vs160
codec=vorbis
comment=EAC 0.95prebeta5 Ogg post-1.0.1&GT3B2 @q5
ctime=1079842502
date=1998
duration=231026
genre=Folk/Rock
length=4509214
offset=0
replaygain_album_gain=-2.35 dB
replaygain_album_peak=1.10969090
replaygain_track_gain=-3.43 dB
replaygain_track_peak=1.10969090
rid=7db600d652093cfe76fd341685deaac3
samplerate=44100
source=Beat the Drum
title=Satellite Flood
tracknr=2
trailer=0
type=tune
mataglap:/drive1/fids/_00022#

When I try to delete either 530 or 531:

mataglap:/drive1/fids/_00022# rm ./531
rm: remove write-protected file `./531'? y
rm: cannot unlink `./531': Operation not permitted
mataglap:/drive1/fids/_00022#

EDIT: yes, the drive was mounted rw.

My first thought is to look at the file attributes -- maybe the immutable bit
got set somehow -- but I can't find binaries for lsattr or chattr.

So I've got two questions for y'all:
1. Does anyone have binaries for lsattr or chattr that they could point me to? They
are part of e2fsprogs. (I haven't had any good luck getting a cross-compile enviro set
up.)
2. Any ideas why I can't delete the bad tag file? Is it safe to delete the two files
(530 & 531) and then rebuild the database? It seems like it should be...

--Nathan

I have to ask - rw or rwm?

Meanwhile, thinking what else might be involved... Can you do an "ls -al" on that file and the next one over?

Yeah, I could have been clearer about that, I suppose. I used "/bin/rwm" to remount /dev/hdc4 & /dev/hda4 in read/write mode. verified with a "cat /proc/mounts". There are no problems ls'ing any of the files:

mataglap:/drive1/fids/_00022# ls -al 5[1-9]*
-rw-r--r-- 1 root root 3490730 Feb 15 09:22 510
-rw-r--r-- 1 root root 425 Feb 15 09:22 511
-rw-r--r-- 1 root root 3462822 Feb 15 09:22 520
-rw-r--r-- 1 root root 420 Feb 15 09:22 521
-rw-r--r-- 1 root root 3951064 Mar 21 16:40 530
-rw-r--r-- 1 root root 3072 Feb 15 09:22 531
-rw-r--r-- 1 root root 4509214 Mar 20 20:15 540
-rw-r--r-- 1 root root 429 Mar 20 20:15 541
-rw-r--r-- 1 root root 7822961 Mar 20 20:15 550
-rw-r--r-- 1 root root 426 Mar 20 20:15 551
-rw-r--r-- 1 root root 3740671 Mar 20 20:16 560
-rw-r--r-- 1 root root 433 Mar 20 20:16 561
-rw-r--r-- 1 root root 4413476 Mar 20 20:16 570
-rw-r--r-- 1 root root 426 Mar 20 20:16 571
-rw-r--r-- 1 root root 6923714 Feb 15 09:23 580
-rw-r--r-- 1 root root 435 Feb 15 09:23 581
-rw-r--r-- 1 root root 5663889 Feb 15 09:24 590
-rw-r--r-- 1 root root 428 Feb 15 09:24 591
mataglap:/drive1/fids/_00022#

and I can cat 521 & 541 successfully.

--Nathan

Hmm... It looks like filesystem errors, but fsck ran clean. Did you use the force tag? (fsck -f) Another thought, can you move (mv) the file into a different directory out of the way? I am not sure how best to proceed otherwise...

Weird.

Try debugfs, which you can grab (temporarily) from here.

To use it on your empeg, do something like this:

./debugfs -w /dev/hda4

rm /fids/_00022/531

quit

If the rm (above) fails, then try the freei command, and if that fails use the unlink command. For freei, you'll first need the inode number, which you can get (before running debugfs) with ls -i /drive0/fids/_00022/531

Good luck!

-ml

Paul, thanks for the suggestions. Yes, I did force the fsck; no, I didn't try a mv because it was the unlink(2) call that failed. A mv to the same filesystem would have just moved the inode reference around and a mv to a different fs would have called unlink as well.

Mark, that did it, it's gone. Thanks! Did you have to do anything other make sure the ...armtools/bin is first in the path to x-compile debugfs? If the e2fsprogs are cross-compile friendly I'll see if I can't get lsattr built as a test case.

--Nathan

I am glad that you got it working! Just a word of clarification - I was hoping you could move the file to /drivex, outside of the fid directory structure so that you could create a new one and resync that way. It is better this way!

Did you have to do anything other make sure the ...armtools/bin is first in the path to x-compile debugfs?

I cheated -- I have some Corel Netwinders around here which have the same CPU as the Empeg, so I just copied the binary from one of those!

Cheers

Or you could hit http://packages.debian.org, and grab the relevant bits from there...

Speaking of compiling for arm:

i've successfully used the skif cluster* at handhelds.org to compile linux binaries for my zaurus sl-c700:

http://www.handhelds.org/projects/skiffcluster.html

Would that not also be useful for quick compiles for the empeg?

-brendan

* a cluster of PDAs...with disk! http://www.handhelds.org/cam.html

Would that not also be useful for quick compiles for the empeg?

Could be... the "distro" on an Empeg is quite old by modern standards, though (GCC 2, glibc 2.1.3) and so if your compile farmlet is at all modern, it won't work.

Peter