Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Drivers
  • Assigned To
    pamaury
  • Operating System All players
  • Severity High
  • Priority Low
  • Reported Version Release 3.4
  • Due in Version Next release
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by kkurbjun - 2010-03-15
Last edited by kkurbjun - 2010-03-16

FS#11107 - Erasing a directory with directory cache does not operate properly

This was tested on the latest SVN with the MR500.

The problem is that if you erase a directory in the root through rockbox when directory cache is enabled it does not remove the directory entry from the list.

Rebooting the player and restarting rockbox still shows the “deleted” directory. Running FSCK shows errors after performing a delete on the player.

I have not tested this without directory cache enabled, but it would be worth double checking with the latest changes.

Steps to reproduce:

 1) With a host machine via USB create a directory "mytest" on the root of the player
 2) Copy some folders with songs into the directory with the host machine
 3) Disconnect the player from the host
 4) Erase the folder through the files menu, note that directory still shows in list.
 5) Run FSCK on the drive (or chkdsk)

This is my output from dosfsck (I renamed the files in the message to make it more clear on the setup):
sudo dosfsck -a /dev/sde1
dosfsck 3.0.3, 18 May 2009, FAT32, LFN
/mytest/folder1/subfolder1

Contains a free cluster (492197). Assuming EOF.

Performing changes.
/dev/sde1: 10689 files, 1192343/1219839 clusters

As a note my directory structure is something similar to the following in case it matters:
→mytest (at root)
_\→folder1
\→subfolder1
_file1
_file2
\→song1.mp3
|→song2.mp3
_\→folder2
\→song1.mp3
__|→song2.mp3

Closed by  kkurbjun
2010-03-16 04:39
Reason for closing:  Fixed
Additional comments about closing:  

Verified fixed in r25203

I’ll have a look at this as soon as possible

I think I know what is the problem. It’s probably due to my last commit where I simplified the dir_uncached code and I missed a little thing. I’m looking for a clean solution.

Ok, I was right. I wrong assumed that fat_opendir was safe to call with the fat_dir as parent and result but I was wrong because I missed some subtle details. I have a fix that I will commit because as far as I can tell, it can’t hurt and should make things work.

And also, this bug is not related to dircacge.
I know there is a bug anyway with dircache that when you delete something, it might still appear in the browser whereas it is in fact deleted but this is a much harder problem to solve and it’s not related to this particuliar bug.

Can you try r25203 ? This should fix the issue.

Thanks for the quick fix! It is working fine with the latest revision.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing