Rockbox

Tasklist

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

Attached to Project: Rockbox
Opened by Karl Kurbjun (kkurbjun) - Monday, 15 March 2010, 06:07 GMT
Last edited by Karl Kurbjun (kkurbjun) - Tuesday, 16 March 2010, 04:39 GMT
Task Type Bugs
Category Drivers
Status Closed
Assigned To amaury pouly (pamaury)
Operating System All players
Severity High
Priority High
Reported Version Release 3.4
Due in Version Next release
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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
This task depends upon

Closed by  Karl Kurbjun (kkurbjun)
Tuesday, 16 March 2010, 04:39 GMT
Reason for closing:  Fixed
Additional comments about closing:  Verified fixed in r25203
Comment by amaury pouly (pamaury) - Monday, 15 March 2010, 08:32 GMT
I'll have a look at this as soon as possible
Comment by amaury pouly (pamaury) - Monday, 15 March 2010, 09:21 GMT
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.
Comment by amaury pouly (pamaury) - Monday, 15 March 2010, 09:52 GMT
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.
Comment by amaury pouly (pamaury) - Monday, 15 March 2010, 09:53 GMT
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.
Comment by amaury pouly (pamaury) - Monday, 15 March 2010, 12:32 GMT
Can you try r25203 ? This should fix the issue.
Comment by Karl Kurbjun (kkurbjun) - Tuesday, 16 March 2010, 04:38 GMT
Thanks for the quick fix! It is working fine with the latest revision.

Loading...