Delete Loop Triggered By Undelete/Flatview

X

xyz321

Well-Known Member
I had my first delete loop for about 10 years and it is reproducible. It is dependent upon undelete and flatview being installed.
Here are the steps to reproduce...
  1. Delete a recording from the flatview directory.
  2. Wait for the two copies (original & flatview) to be moved to the [Deleted Items] directory.
  3. Undelete the 'main' copy by moving it out of the [Deleted Items] directory to its original location.
  4. Wait for a new flatview entry to be created.
  5. Delete the entry under the flatview directory for a second time.
To stop the loop:
Code: 
rm -f "/media/My Video/[Deleted Items]/<recording name>.*"

I think the undelete/flatview packages should not create flatview entries under [Deleted Items].
 
By "delete loop", I presume you mean it's got the "deleting" on-screen spinner interminably, but nothing's happening (as opposed to the destructive loop). Does it survive a reboot?

xyz321 said:
I think the undelete/flatview packages should not create flatview entries under [Deleted Items].
Click to expand...
I think flatview should be ignoring folders prefixed "[" the same as any other auto package, but perhaps that's not what you mean. Is this primarily an undelete thing? As one of the original packages, I guess it's pretty primitive and never designed to cope with the fancy stuff.
 
Yes, it has the on-screen spinner which survives a reboot.

It is quite a while since I looked at flatview and much of it has been rewritten since I was last involved. As I remember flatview would ignore folders prefixed by '[' or '_'. Flatview calls the undelete funtion 'safe_delete' when deleting recordings so that they will end up in the '[Deleted Items]' folder. Since the code has changed quite a lot I am not sure of the current split between flatview and undelete.

Currently if the main recording is deleted then only that will appear in '[Deleted Items'. If instead the Flatview entry is deleted then both that and the original recording will appear under '[Deleted Items]'. This is bad not only for the delete loop but also because both recordings are the same inode. If the Humax app is used to delete one of the copies within 'Deleted Items' then the remaining one will be truncated due to the way the Humax app deletes files with repeated truncations followed by a delete.

The root of the problem is the error handling of the Humax software and/or the intreraction with undelete. The undelete function attempts to move a recording to the '[Deleted Items]' folder but the file already exists so it fails. Usually functions return a non-zero exit status on failure and the calling function should abort. In this case it seems the calling function (within the humax app) is repeatedly retrying the undelete function, since 'humaxtv.log' shows repeated attempts to move it.
 
xyz321 said:
The root of the problem is the error handling of the Humax software and/or the intreraction with undelete. The undelete function attempts to move a recording to the '[Deleted Items]' folder but the file already exists so it fails. Usually functions return a non-zero exit status on failure and the calling function should abort. In this case it seems the calling function (within the humax app) is repeatedly retrying the undelete function, since 'humaxtv.log' shows repeated attempts to move it.
Click to expand...
Very good.

I'm having a bit of difficulty stringing the elements together:
  • The flatview package works by creating alternative additional directory indexes (the [FlatView] folder in My Video) to the same actual data on disk, which also remains indexed in its original folder. A count of the number of indexes to any particular data is maintained, and deleting an index decrements the count (not the actual data) until the count reaches zero, when the space the data occupies is then made available for reallocation.

  • WIthout undelete, when the original file entry is "deleted", I presume the hard link count is decremented and only the folder index gets removed, then (I presume) the flatview code tracks the change and removes the index in the [FlatView] folder which actually deletes the file (link count having reached zero).

  • WIthout undelete, if the [FlatView] file entry is deleted instead, I presume the flatview code tracks the change and reflects that back to the original folder, thus deleting the file.

  • WIth undelete, deletion (via humaxtv or WebIF, not FTP/SMB/NFS) is intercepted and converted to a move to the waste basket (which merely moves the directory index from where it was to the [Deleted Items] folder, without moving or removing any file data).

  • WIth undelete, if the [FlatView] file entry is "deleted" and undelete intercepts the deletion, I presume the index is moved to [Deleted Items] with no decrement of link count. Then patching up by flatview to reflect the change in the original folder attempts a move to where an index of the same name already exists, and it fails.

  • WIth undelete, when the original file entry is "deleted", why doesn't the same thing happen (in reverse), and fail also?
My head hurts.

What is the chain of events if the deletion is performed via WebIF? I presume something similar going to happen, but it just fails instead of triggering a deadly embrace (as per humaxtv)?

PS: May I suggest retitling this thread "Delete Loop Triggered By Undelete/Flatview"?
 
Last edited:
Black Hole said:
  • WIth undelete, when the original file entry is "deleted", why doesn't the same thing happen (in reverse), and fail also?
Click to expand...
Assuming this refers to the scenario in the OP it is because the 'original' was manually moved out of '[Deleted Items]' before it was 'deleted' for a second time. Flatview/undelete handle the already present entry in the flatview sub-directory of [Deleted Items] in this case.

Black Hole said:
What is the chain of events if the deletion is performed via WebIF? I presume something similar going to happen, but it just fails instead of triggering a deadly embrace (as per humaxtv)?
Click to expand...
I suspect it will be okay but will need to do more tests.
 
Aarrggg!!!! In trying to unpick it all, I forgot a whole layer. I was trying to work out whether it would be best to modify flatview or undelete (and wrap my mind around some spherical geometry at the same time).
 
...the effect of which is like having your brains smashed out by a slice of lemon wrapped around an inode conundrum.
 
You must log in or register to reply here.
Back
Top