It's not a problem I'm just curious really, why deleting a recording on the Foxsat HDR takes several seconds.

Normally file deletes on computers are pretty instantaneous since all that actually happens is that the directory entry is removed and the relevant disk space marked as free, the data itself still exists until it gets overwritten.

The time it takes for the HDR to delete suggests that the data itself is getting deleted akin to a 'security wipe'. I can't think why this would be deemed to be necessary though, so is there another explanation?

The HDR uses the UNIX filesystem. Here is a link to explain how deleting works on this filesystem:-

http://www.dataexpedition.com/~sbnob...lesystems.html

As you will see deleting is far more complex than just removing a single entry from the file allocation table.

Thanks Richard, but I'm pretty familiar with Linux and ext3, and doing 'rm <file>' or even a whole directory of files is virtually instantaneous, unless, as I said, you choose to use something like 'shred' to actually wipe the data.

In the ext file system blocks that are deleted must be verified and while the HDR does this in the most economical way it does require the process to happen. Recordings are typically GB in size and as a result the CPU must spend time processing this function. It does this at low priority compared to other tasks so as reduce the impact on the broadcast reception side and as a result it takes time for a file to be deleted on the modest CPU. The product has a 400MHz MIPS single thread CPU to do all of it's functions including most of the graphics.

Any chance you can clarify what you mean by this? Are you talking about bad-block detection? If so, I'm surprised this isn't left to the disk drive itself since I believe most drives include auto-relocation/remapping of bad sectors these days.

To quote Andreas Dilger one of the developers of the ext3 file system:

This is the more intensive process that takes time.

Bob

Why cant it use the same system as Sky or even the old Humax 9200T when it was instant or at least deleted it in the background while you did something else ?

I think it does do it in the background - It's just that a flashing icon shows you it is happening. I think the only things you can't do is delete another file or start a file copy?

Correct. You can even drop the HDR into standby during a lengthy delete. There will be delay while it finishes then it enters standby.

I've never been a great fan of the Ext variants. The fact they don't tend use RLE for blocks annoys me.

I prefer HPFS because it uses RLE in a B+Tree but also tries to keep FNodes close to the data they describe. It made recovering data a lot more reliable.

Second best would be NTFS. I'm not keen on the centralised MFT but I like the way it encodes block allocations. I also love the way it's basically a superset of pretty much any other FS. About the only one we had to deal with that it couldn't mimic was AS400 - and that's not really a file system anyway.

But the problem with NTFS is writing it. Reading is okay but there's so much you have to get right when you're writing to it

What an extraordinary way of doing it. Surely rebuilding the free block chain on those comparatively rare occasions you need to recover is the better and more efficient way overall.

Andrue,

I agree it isn't my favourite either. Apparently HQ have been doing some R&D on this subject as we head toward advanced next generation products.

Bob

Apologies for resurrecting an old thread. I find deleting things using the media list a bit tedious and am wondering whether deleting via FTP may be a more efficient way of doing things. Given the info above, will deleting via FTP have the same effect as deleting via the media list? I would hate to have the programs disappear but the free space not released.

For comparison I have just done a delete of a 2G file on a slow computer with ext3. Took 4.5 seconds including 0.5 seconds CPU time. This on a 550MHz Pentium III.

So yes, large file deletes can take a little while.