Hello. I installed TomatoUSB Ext on my Asus WL500gP today. To it I connected my USB harddrive running NTFS. Everything worked pretty well, except for a very laggy SMB, until I switched on the Media Server and let it scan my Movies folder. Imagine my surprise when it was all gone. Now I'm a very sad panda. Any ideas for a NTFS file rescue that does not require a second disk?
Date: 01 Sep 2010 13:40
Number of posts: 9
RSS: New posts
Too bad :(…
I can't help you with restoring the files - I guess you may google something out. But way in the past "File Scavenger" did wonders for me when everything else failed (not free though).
Was there anything in the system log that could shed a light on what actually happened? Where is your media database located (what did you specify in the GUI)?
I looked through the MiniDLNA and SQLite code for all occurrences of "unlink", "rmdir" etc calls - and could not find anything that gives a clue… Must be some bad bug somewhere. But I could not reproduce it - when I tested it myself on RT-N16 with 1TB WD NTFS drive, it worked fine and didn't delete anything after about ~40 scans…
It's not the end of the world, but makes me worried if there is a bug in the NTFS driver as I have a lot of personal stuff on that drive. Good thing I didn't let it scan the entire drive… The log just says creating database, scanning and finished (0 files). I put the database in the media root. Could that be it? The only items left is the database file and the directory that was occupied by a ssh terminal during the incident.
I don't think it's NTFS driver problem, as I'm using it extensively, and never ran into an issue with it.
But it could be related to the fact that the database was in the media root - I wonder if it gets confused and cleans up the whole directory instead of just the database file. I'll play with it more - before I only tested it with the database in RAM or in it's own directory.
EDIT: Heh!.. I looked through the MiniDLNA code again. Guess what is there:
case 'R': snprintf(real_path, sizeof(real_path), "rm -rf %s", db_path); system(real_path);
where db_path is just the directory name, NOT the database file name!!!
I guess it does it to clean up the album art cache stored in the same directory, as well as the database. Oh well… I'll change it so in the future builds it will create another folder underneath the one specified.
For now, just DO NOT SPECIFY THE ROOT OF YOUR MEDIA FOLDER AS THE DATABASE PATH.
running build 48…
1.5GB of data… GONE!!!
thats a pretty terrible bug, "rm -rf" should not be abused…..
and dont try to tell me its read-mail really-fast(haha)
going to try to recover…
That's why you should check the changelog from time to time for any critical fixes like that one :)…
Especially when running "beta" firmware…