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

[Mundosat]

I said why not, but I should have said: Can it be fixed ?
I am just an advanced user trying to delete it.

[ccs]

I'm surprised you can't see it in Filezilla.

Under server there is an option to "Force show hidden files".

.Trash disappears from view when I unset it.

[Mundosat]

Checked that and set it to show hidden files, I can see it now - thanks - never thought about that, as servers usually show all files!

In the meantime last night folder has disappeared and it probably was after I 'strangely' found bin cleaning set to 15 days and reduced to 7 and I guess after going in st-by and re-starting later on must have had system check dates and deleted it as it was probably 8-9 days now. That is why I put it on 7 days to see if it do it and it did delete it.

[Willo3092]

Is there any way of deleting a directory immediately then with trash can disabled and cleaning of network drives enabled? I know you used to be able to do it and it still works like that on ATV.
At the moment I have to use DreamExplorer' to delete directories. All that happens in the movie list is that it appends multiple .del's.

This is from the log:

17:20:31.2025 [eBackgroundFileEraser] deleting '/media/autofs/RECORDINGS/Urban Myths.del.del'
17:20:31.2027 [eBackgroundFileEraser] removing /media/autofs/RECORDINGS/Urban Myths.del.del failed: Is a directory

[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.

[Willo3092]

I did some googling and it seems to be something to do with the background file eraser.

I just ended up putting a script in cron.hourly to delete any directory ending with .del

[simonc]

I think you get the .del.del.del thing if you go to look at deleted things in the bin and re-delete them before the background eraser has removed them.

[Willo3092]

I don't have the bin enabled at all though. When I delete stuff I just want it gone.
The pli forum suggests that background file eraser deletes things a chunk at a time and it can take a while.
I will have to have a look and see how ATV do it because that seems to work as expected when the trash is disabled.

[Willo3092]

Just tried it on ATV 7.0 with a directory with a few random files in it and it deleted fine.
It doesn't seem to mention file eraser like ViX does though.

2021-08-31 20:38:28+0100 [-] [InfoBarGenerics] Key: 398 (Break) KeyID='KEY_RED'.
2021-08-31 20:38:28+0100 [-] [ActionMap] Keymap 'ColorActions' -> Action 'red'.
2021-08-31 20:38:28+0100 [-] [Skin] Processing screen 'MessageBox', position=(240, 160), size=(800x400) for module 'MessageBox'.
2021-08-31 20:38:28+0100 [-] [Screen] Warning: Skin is missing element 'icon' in <class 'Screens.MessageBox.MessageBox'>('AAAA' contains 5 file(s) and 0 subfolders.
2021-08-31 20:38:28+0100 [-] Are you sure you want to delete?).
2021-08-31 20:38:28+0100 [-] [Pixmap] setPixmapNum(0) failed!  Defined pixmaps: [].
2021-08-31 20:38:28+0100 [-] [Skin] Processing screen 'MessageBox_summary' from list 'MessageBox_summary, SimpleSummary', position=(0, 0), size=(1x1) for module 'SimpleSummary'.
2021-08-31 20:38:28+0100 [-] [Screen] Showing screen '['MessageBox_summary', 'SimpleSummary']'.
2021-08-31 20:38:28+0100 [-] [Screen] Showing screen '['MessageBox']'.
[eRCDeviceInputDev] 1 160 1
2021-08-31 20:38:33+0100 [-] [InfoBarGenerics] Key: 352 (Make) KeyID='KEY_OK'.
2021-08-31 20:38:33+0100 [-] [ActionMap] Keymap 'MsgBoxActions' -> Action 'ok'.
2021-08-31 20:38:33+0100 [-] [Screen] Showing screen 'MovieSelectionSummary'.
2021-08-31 20:38:33+0100 [-] [Screen] Showing screen 'MovieSelection'.
2021-08-31 20:38:33+0100 [-] [DeleteFolderTask] files  /media/autofs/RECORDINGS/AAAA
2021-08-31 20:38:33+0100 [-] job Components.Task.Job name=Deleting files #tasks=1 completed with [] in None
[eRCDeviceInputDev] 0 160 1

This is the log from ViX 5.5 for exactly the same thing:

20:49:48.6296 [InfoBarGenerics] Key: 398 (Break) KeyID='KEY_RED' Binding='('RED',)'.
20:49:48.6299 [ActionMap] Keymap 'ColorActions' -> Action = 'red'.
20:49:48.6431 [Skin] Processing screen 'MessageBox', position=(0, 0), size=(1920 x 1080) for module 'MessageBox'.
20:49:48.6643 [Screen] Warning: Skin is missing element 'icon' in <class 'Screens.MessageBox.MessageBox'>(Do you really want to permanently delete 'AAAB'?).
20:49:48.6687 [Pixmap] setPixmapNum(0) failed! defined pixmaps: []
20:49:48.6699 [Skin] Processing screen 'MessageBox_summary' from list 'MessageBoxSummary, ScreenSummary, MessageBox_summary, SimpleSummary', position=(0, 0), size=(1 x 1) for module 'ScreenSummary'.
20:49:50.3378 [eInputDeviceInit] 1 160 (352) 1
20:49:50.3382 [eRCDeviceInputDev] emit: 1
20:49:50.3401 [InfoBarGenerics] Key: 352 (Make) KeyID='KEY_OK' Binding='('OK',)'.
20:49:50.3404 [ActionMap] Keymap 'MsgBoxActions' -> Action = 'ok'.
20:49:50.3625 [eThread] old thread joined 0
20:49:50.3628 [setIoPrio] best-effort level 7 ok
20:49:50.3629 [eBackgroundFileEraser] deleting '/media/autofs/RECORDINGS/AAAB.del'
20:49:50.3630 [eBackgroundFileEraser] removing /media/autofs/RECORDINGS/AAAB.del failed: Is a directory
20:49:50.5465 [eInputDeviceInit] 0 160 (352) 1

[simonc]

Might be related to the multiselect changes from earlier this year. I'll take a look.

[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.

[ccs]

... that's what I thought when I had a look at the code, a massively complicated process to slow down the deletion of (a number of) files.

Maybe there was an impact on performance once upon a time, but I can't really see why it should be such a problem.

I'd simplify it and see if there are still any issues.

[simonc]

Ah, the multiselect additions broke deleting directories when not using the trashcan. I'm not surprised I screwed it up: the old the MovieSelection delete was one of those functions that works out what to do and displays a message box, then calls back onto itself with a flag saying "do the thing I've just worked out what to do". Great idea, no need to write 2 functions when you could save a bit of typing.

Amusingly, directory deletion was previously completely bypassing the background delete job and just using rmtree, so if no-one has had problems with deleting directories permanently prior to the introduction of this bug, then the background eraser isn't doing anything useful.

[BrokenUnusableAccount]

I don't have the bin enabled at all though. When I delete stuff I just want it gone.
The pli forum suggests that background file eraser deletes things a chunk at a time and it can take a while.
I will have to have a look and see how ATV do it because that seems to work as expected when the trash is disabled.

Ah, the multiselect additions broke deleting directories when not using the trashcan. I'm not surprised I screwed it up: the old the MovieSelection delete was one of those functions that works out what to do and displays a message box, then calls back onto itself with a flag saying "do the thing I've just worked out what to do". Great idea, no need to write 2 functions when you could save a bit of typing.

Amusingly, directory deletion was previously completely bypassing the background delete job and just using rmtree, so if no-one has had problems with deleting directories permanently prior to the introduction of this bug, then the background eraser isn't doing anything useful.

Yes. I'm not convinced that deleting needs to be slowed down in most cases. Linux has enough buffers to cope if a large deletion takes up to maybe around half a second.
I would think the only case that might take longer would be on some SSDs that have rather dumb implementations of TRIM, if TRIMming is done as the deletions are done.
Or if you're doing dsecure erasing for some weird reason.

Linux EXT file systems aren't particularly slow at deleteing stuff are they?