Cannot delete folder from' Delete folder' + various other small problems ...

[Mundosat]

That is the problem.

I might not have explained it well.

I did go there and deleted it, but it reappears, it now had about 4x .del.del.del.del on it!

I will amend my initial message to reflect that.

[BrokenUnusableAccount]

That is the problem.

I might not have explained it well.

I did go there and deleted it, but it reappears, it now had about 4x .del.del.del.del on it!

I will amend my initial message to reflect that.

Yes the .del.del.del.del thing is a, probably harmless, bug with the delayed deletion feature.

[birdman]

Yes the .del.del.del.del thing is a, probably harmless, bug with the delayed deletion feature.

The descriptions so far imply that the background eraser won't delete a directory - ever.

[simonc]

Here's the smoking gun:

 
18:49:51.4987 [eBackgroundFileEraser] deleting '/media/hdd/movie/k.del'
18:49:51.4989 [eBackgroundFileEraser] removing /media/hdd/movie/k.del failed: Is a directory

I can't currently determine why ATV deletes directories successfully and Vix doesn't. There are only slight differences on Vix with the filename processing in the file_eraser.cpp, which is where this message originates.

Can anyone shed any light on why deleting a file is considered so heavyweight that it has to be done in a background thread with masses of complicated checks for the size of files being deleted? The initial commit for the background eraser says what it does, not why it's being added. I'd wondered if it was due to slow or unreliable network drives, but if that was the case, then renaming to postfix .del on the filename would be just as laggy as removing the file from the filesystem index. The size of the file being deleted shouldn't have any effect on how quick it is to delete the file, so I also don't understand why there's a delete speed in the movielist settings.

By comparison, on the internal HDD, deleting a file using Python's os.remove or an entire directory tree of hundreds of files using shutils.rmtree is consistently a sub-second operation.