View Full Version : Cannot delete folder from' Delete folder' + various other small problems ...
Note: please read Deleted folder as Deleted items [folder] :)
:confused:
Hi
Last week I deleted a folder from my 'movie' main folder, then went to the Deleted items and deleted it.
Next time I went there to delete other recordings, I saw that folder there again, but named FolderName.del [.del added to it] - I guess that is the append of some sort System uses to 'mark' it as to delete?
Anyway, I re-deleted it and I went back to the Deleted items and it was still there and System keeps adding.del on it.
Now I have FolderName.del.del.del
I am trying to find it using Filezilla, but I am guessing this folder must be listed within some XML and until it goes from there it keeps appearing?
One information that might be important to the developers: when I 'first' deleted this folder - it had some recordings in it - i.e. I deleted a folder with contents in it.
Might that have caused something?
Possibly being a bug in deletion ... when recordings are in a deleted folder it does not like it?
How can I delete it?
Thanks for your help
M
PS a few small problems - nothing big ... I thought to mention them:
Since last 2 updates
- I do not remember what was exactly the first time, but to do with subtitling [it rebooted]
[second time] while switching subtitle type from 888 to DVB, I got an error and it rebooted again, but both reboots about subtitles.
- both times on recordings and to do with subtitles.
- other thing I always had is [again subtitles!] that very often they do not start and I found a way to make them start and on sync.
I simply run recording, then press Subtitles button and switch from 888 to DVB and then STOP playing and START playing and subtitles works fine.
Hi,
try pressing menu. I think there should be an option to really delete the deleted files. It look like the same procedure as for bouquets.
Ralf
Will try now my grandson is not there!
:thumbsup:
You can also select deleted items from the movielist, and delete it, you will then be asked if you really want to permanently delete its contents.
Not working, still there.
As I mentioned ,there must be a file [possibly a XML] telling Enigma that it still is there and to mark it for deletion.
I am no developer, but it seems the logical explanation ... to me at least.
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.
Don't go into the deleted items folder to delete it - do it from the movie list - press MENU and select "empty trash can"
The 2nd entry in Movielist/menu/settings is Remove items from trash can after (days)
I don't have the deleted items / trashcan enabled on my boxes but the same thing is happening. Every time I delete a folder it just appends .del to it.
I have to delete folders from my PC at the minute.
61568
I have just tested it and if you delete the folder from within with recycle bin it adds the .del to it but if you actually empty the bin it does delete it.
As I recall the del gets added and a background job is sent off to delete things.
If this background job fails the *.del entry will still be there.
So perhaps something is actually failing in the deletion?
Is the code using rm -rf dirname ? A directory needs to be empty before you can delete it (or else you recursively/force delete it).
Is the code using rm -rf dirname ?No. It's in Python at the time, so would be using rmtree.
However, the second crash log posted contains this:
<168517.0916> 20:39:02.8753 [ActionMap] Keymap 'MsgBoxActions' -> Action = 'ok'.
<168517.0927> 20:39:02.8764 [Screen] Showing screen '['ChoiceBoxSummary', 'ScreenSummary', 'ChoiceBox_summary', 'SimpleSummary']'.
<168517.0942> 20:39:02.8778 [Screen] Showing screen '['LocationBoxSummary', 'ScreenSummary', 'LocationBox_summary', 'SimpleSummary']'.
<168517.0969> 20:39:02.8805 [Screen] Showing screen '['ChoiceBox']'.
<168517.0976> 20:39:02.8813 Traceback (most recent call last):
<168517.0977> 20:39:02.8813 File "/usr/lib/enigma2/python/mytest.py", line 238, in processDelay
<168517.0990> 20:39:02.8827 callback(*retval)
<168517.0991> 20:39:02.8828 File "/usr/lib/enigma2/python/Tools/BoundFunction.py", line 9, in __call__
<168517.0994> 20:39:02.8831 File "/usr/lib/enigma2/python/Screens/LocationBox.py", line 283, in removeDirCallback
<168517.0996> 20:39:02.8832 File "/usr/lib/enigma2/python/mytest.py", line 329, in open
<168517.0998> 20:39:02.8835 raise RuntimeError("modal open are allowed only from a screen which is modal!")
<168517.0999> 20:39:02.8836 RuntimeError: modal open are allowed only from a screen which is modal!
<168517.1000> 20:39:02.8836 [ePyObject] (CallObject(<bound method Session.processDelay of <__main__.Session instance at 0xb016df80>>,()) failed)
(The first one contains an issue that has since been fixed).
Is the code using rm -rf dirname ? A directory needs to be empty before you can delete it (or else you recursively/force delete it).
Exactly as I thought and mentioned and I am no developer but it seems obvious is what it is.
Still, why not?
As birdman pointed out, the directories are being managed by a Python module and it has a utility rmtree which does the necessary system commands to remove a directory recursively.
I said why not, but I should have said: Can it be fixed ?
I am just an advanced user trying to delete it.
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.
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.
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
31-08-21, 17:07
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.
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
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.
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.
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
Might be related to the multiselect changes from earlier this year. I'll take a look.
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.
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.
... 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.
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
05-09-21, 01:03
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?
The especially odd thing about the background deletion is that it does an ltrunc on each file, shortening it by 20MB at a time until it has zero length. I just can't see how this can possibly be any more efficient or light on CPU than just removing the file's index entry with unlink. This has the smells of someone looking for a problem to apply a clever solution to. Now, if they'd commented it with workaround for unlink being slow across networks/due to a bug in drivers on Miraclebox 123 then we'd know where we were.
Is there a comment/warning somewhere about recordings in progress/about to start? Would this be the reason why the the files are not removed by rm or unlink?
You may be onto something; when you delete an in progress recording, it stops the timer, then tells the background deleter to remove the file. The recording code runs in a background thread, so it may not stop writing before the deleter starts. There's no useful comments to back this idea up though.
PLi reckon it's because deleting large files on slow media can cause recording stutters. Probably related to the way Linux's ext filesystem organises the chunks of a large file.
Found this on SuperUser
When deleting a file, the ext3 filesystem will actually zero out the block pointers (http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html#undelete) in the inode (https://en.wikipedia.org/wiki/Inode_pointer_structure). The larger the file, the more blocks, and the more block pointers, thus the delete operation takes longer on larger files than smaller ones.
This is different behavior than both ext2, which merely zeroes out the inode and leaves the blocks containing the block pointers intact (but marked as free) and ext4, which uses extents (http://digital-forensics.sans.org/blog/2010/12/20/digital-forensics-understanding-ext4-part-1-extents) (and, since extents are a much more compact structure, has much better delete performance, that slows down based on how fragmented the file is, rather than how big it is).
Linux has enough buffers to cope if a large deletion takes up to maybe around half a second.
Deleting just removes the entries in the directory and frees the extents. It shouldn't take long, and not much I/O.
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.Only if you set the option, which isn't recommended. Better to run an fstrim once a week (which is effectively what MSWindows does too).
BrokenUnusableAccount
06-09-21, 01:59
Deleting just removes the entries in the directory and frees the extents. It shouldn't take long, and not much I/O.
Only if you set the option, which isn't recommended. Better to run an fstrim once a week (which is effectively what MSWindows does too).
My Windoze 7 PCs definately do TRIM as they delete. I notice that deleting larges files from my SSD lights the disk access light much longer than deleteing them from an HDD does.
My Windoze 7 PCs definately do TRIM as they delete.Well, they do scheduled TRIMs too.
Go to the disk/partition on file explorer, select Properties/Tools and click on Optimise. If you select to optimize an SSD it runs a TRIM on it. (My Windows partition currently says "OK (23 days since last retrim)". It's scheduled to run weekly (but I don't boot into Windows all that often, nor for very long).
If it's TRIMming on each deletion as well then it's just wasting time and effort.
"fsutil behavior query DisableDeleteNotify" does say that TRIM is enabled. Hmmm.....might help to explain some slow Windows actions. Might try changing it...
BrokenUnusableAccount
07-09-21, 01:48
Well, they do scheduled TRIMs too.
Yes I think I remember seeing that Win 10 does scheduled TRIMs. But Win 7 doesn't, well not unless they hid it really well anyway.
I don't know if Win 10 does TRIMs as it goes as well as scheduled.
I assume a well designed modern SSD shouldn't slow anywhere near much as my old SATA ones do when TRIMming.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.