По следам этого топика заинтересовала проблема испорченного файла, который не удаляется. Никогда с таким не сталкивался, проверить лично не могу, но попробую хотя бы описать возможный способ для решения данной проблемы. Кроме того, используя debugfs можно получить много дополнительной информации о файловой системе и, в некоторой степени, даже выполнять определенные изменения. Работу с данной утилитой не описываю, отсылаю к man и DOC, а вот в части применения к данному случаю опишу подробно. .... И да, будте внимательны в режиме внесения изменений - семь раз подумай, один раз отрежь.

С данной тематикой немного знаком, а потому видится следующий способ решения проблемы при удалении файла - очистка блока inode - блок обнулится и система должна перестать видеть данный файл. 100% гарнтии нет, НО если даже и не поможет, информация думаю будет полезна.
Показывать буду на нормальном файле /home/vasek/TTT/TEST/TEST.txt
1. Разминка - ознакомление, НЕ ОБЯЗАТЕЛЬНОЕ - этого можно ничего и не делать, привожу для понимания.
Узнаем номер inode данного файла
ls -i /home/vasek/TTT/TEST/TEST.txt
655365 /vasek/TTT/TEST/TEST.txt
Иногда это и не получится сделать (как в случае указанного выше топика), тогда используем следующую команду
sudo debugfs -R 'imap /home/vasek/TTT/TEST/TEST.txt' /dev/sda3
Inode 655365 is part of block group 80
	located at block 2621472, offset 0x0400
Чем хорош этот вывод - узнаем и номер inode и расположение на диска блока inode, соответствующему данному файлу. Блок inode составляет 256 байт (там не много все сложнее - 128 байт и плюс расширение, а важны только 128 байт - но не будем с этим заморачиваться) и в нем содержится практически вся информация о файле, которую другие утилиты парсят из этого блока.
И так, строчка located at block 2621472, offset 0x0400 несет информацию о расположении блока inode на разделе, точнее показывает смещение от начала раздела. Зная это и выполнив соответствующий расчет (от начала раздела sda3 = 2621472 * 4096 + 1024 = 10737550336 ) вытаскиваем этот блок с диска
sudo hexdump -C -s 10737550336 -n 256 /dev/sda3
280020400  a4 81 e8 03 06 00 00 00  5c d2 4a 5e 38 70 4b 5e  |........\.J^8pK^|
280020410  5c d2 4a 5e 00 00 00 00  64 00 01 00 08 00 00 00  |\.J^....d.......|
280020420  00 00 08 00 01 00 00 00  0a f3 01 00 04 00 00 00  |................|
280020430  00 00 00 00 00 00 00 00  01 00 00 00 fe bf 28 00  |..............(.|
280020440  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
280020460  00 00 00 00 60 0c 86 31  00 00 00 00 00 00 00 00  |....`..1........|
280020470  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
280020480  20 00 00 00 10 5e f9 3a  78 9d 07 0d cc 10 d3 0d  | ....^.:x.......|
280020490  5c d2 4a 5e 78 9d 07 0d  00 00 00 00 00 00 00 00  |\.J^x...........|
2800204a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
280020500
Проверим - по смещению 8-11 (4 байта) находится время последнего доступа к файлу
5c d2 4a 5e --- 5e4ad25c --- 1581961820, что соответствует Пн 17 фев 2020 20:50:20 MSK
Проверяем (и убеждаемся в совпадении, с точностью до секунд, дробные в расчет не брал)
stat -c%x /home/vasek/TTT/TEST/TEST.txt
2020-02-17 20:50:20.057984051 +0300
Если полностью очисть этот блок (точнее 128 байт), то файл исчезнет - система о нем знать не будет - это можно проделать как в ручную (самый надежный способ), так и с помощью утилиты debugfs, но вот всегда ли это сработает, практически 100% уверенности нет, но теоретически должно сработать.

2. Процесс очистки inode с использованием debugfs
В linux есть очень хорошая утилита debugfs, с ее помощью можно очень многое проделать, в ней действуют все те же команды, что и в обычном bash (ls, cat, stat, rm и др.) плюс к этому можно вытащить очень много полезной информации, вплоть до удаленных файлов. Но редко кто пользуется этим - все привыкли к GUI.
В работающей системе утилита запускается в режиме read only и можно только просматривать информацию, а вот менять не возможно. Для этого нужно перевести систему в режим записи и лучше отмонтировать. А так как нам нужно будет вносить изменения, то буду грузиться с Live CD … я могу загрузиться и с образа archiso, расположенного на диске, в этом же разделе, НО лучше оставить раздел, с которым будем работать, в покое, а потому загружусь с флешки, на которой несколько образов, но я для удобства выберу systemrescuecd-6.0.0 (нужно будет копировать команды и их вывод в файл и сохранить все это на флэшке).

PS - чем мне нравится systemrescuecd-6.0.0 - он сделан на основе ArchLinux, а если запустить startx, то попадаешь в DE xfce - очень удобно.

И так приступим, загрузились и запускаем debugfs, конечно, перед началом рекомендую уточнить разделы утилитой fdisk или альтернативной командой
sudo debugfs /dev/sda3
debugfs:
... получаем строку приглашения для ввода команд и смотрим наш файл в нужной директории ...
debugfs: ls -l /home/vasek/TTT/TEST
…….
655365 100644 (1) 1000 100 6 17-Feb-2020 20:50 inode
……
номер inode 655365 совпадает с приведенным в начале ... то есть можно было его и не узнавать перед этим, но так спокойнее - лишняя проверка не помешает
Посмотрим информацию из блока inode (hex вывод блока inode был приведен выше)
debugfs: mi <655365>
mi: Filesystem opened read/only
… нам напоминают, что система только для чтения - переведем в режим записи
debugfs: open /dev/sda3 -w
open: Filesystem /dev/sda3 is still open. Close it first.
… говорят, что сначала закройте … закроем и снова откроем (обычно на этом большинство спотыкается)
debugfs: close_filesys -a
debugfs: open /dev/sda3 -w
debugfs:
… все нормально - ожидание для ввода команд - посмотрим инфу inode
debugfs: mi <655365>
… для листания Enter, для выхода q ...
                          Mode    [0100644]
                       User ID    [1000]
                      Group ID    [100]
                          Size    [6]
                 Creation time    [1582002232]
             Modification time    [1581961820]
                   Access time    [1581961820]
                 Deletion time    [0]
                    Link count    [1]
              Block count high    [0]
                   Block count    [8]
                    File flags    [0x80000]
                    Generation    [0x31860c60]
                      File acl    [0]
           High 32bits of size    [0]
              Fragment address    [0]
               Direct Block #0    [127754]
               Direct Block #1    [4]
               Direct Block #2    [0]
               Direct Block #3    [0]
               Direct Block #4    [1]
               Direct Block #5    [2670590]
               Direct Block #6    [0]
               Direct Block #7    [0]
               Direct Block #8    [0]
               Direct Block #9    [0]
              Direct Block #10    [0]
              Direct Block #11    [0]
                Indirect Block    [0]
         Double Indirect Block    [0]
         Triple Indirect Block    [0]
… ну вот видим часть информации из блока inode, но в человеческом виде, а не в hex-code. Замечаем, что время последнего доступа к файлу равно - Access time [1581961820], что соответствует значение, вытащенному напрямую из блока inode - 5c d2 4a 5e — 5e4ad25c — 1581961820
Приступим к очистке inode
debugfs: clri <655365>
и снова смотрим информацию inode
debugfs: mi <655365>
                          Mode    [00]
                       User ID    [0]
                      Group ID    [0]
                          Size    [0]
                 Creation time    [0]
             Modification time    [0]
                   Access time    [0]
                 Deletion time    [0]
                    Link count    [0]
              Block count high    [0]
                   Block count    [0]
                    File flags    [0x0]
                    Generation    [0x0]
                      File acl    [0]
           High 32bits of size    [0]
              Fragment address    [0]
               Direct Block #0    [0]
               Direct Block #1    [0]
               Direct Block #2    [0]
               Direct Block #3    [0]
               Direct Block #4    [0]
               Direct Block #5    [0]
               Direct Block #6    [0]
               Direct Block #7    [0]
               Direct Block #8    [0]
               Direct Block #9    [0]
              Direct Block #10    [0]
              Direct Block #11    [0]
                Indirect Block    [0]
         Double Indirect Block    [0]
         Triple Indirect Block    [0]
Все обнулилось, а значит система не должна больше ничего знать об этом файле. Выходим и перегружаемся.

3. Загрузка после проведенных работ.
По идее нужно сразу при загрузке выполнить проверку fsck -fv /dev/sda3, зарузившись с параметром break или break=premount … количество свободных inode изменилось, да и кое что еще во внутренностях ext4 изменилось - пусть система все проверит, изменит и запишет …. но мы сейчас этого не делали - интересно посмотреть сразу же (до проверки), до всяких изменений, как будет выглядеть блок inode.
И так, загрузились успешно, смотрим этот файл
ls /home/vasek/TTT/TEST/TEST.txt
ls: невозможно получить доступ к '/home/vasek/TTT/TEST/TEST.txt': Структуру необходимо почистить
Вот нам система и сама напоминает о проверке … заодно смотрим старый блок inode
sudo hexdump -C -s 10737550336 -n 256 /dev/sda3
280020400  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
280020480  20 00 00 00 10 5e f9 3a  78 9d 07 0d cc 10 d3 0d  | ....^.:x.......|
280020490  5c d2 4a 5e 78 9d 07 0d  00 00 00 00 00 00 00 00  |\.J^x...........|
2800204a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
280020500
Видим одни нули (128 байт нули, за исключением расширения, 24 байт, но они отношения к нашему файлу не имеют - кстати, эти байты всегда будут одни и те же).
И все таки я перегружусь и сделаю проверку fsck …. перегрузился, проверился, но проверка выполнилась автоматом, сама - но я все равно запустил повторно

Загрузились, проверяем повторно
ls /home/vasek/TTT/TEST/TEST.txt
ls: невозможно получить доступ к '/home/vasek/TTT/TEST/TEST.txt': Нет такого файла или каталога
Заодно смотрим старый блок inode
sudo hexdump -C -s 10737550336 -n 256 /dev/sda3
280020400  a4 81 e8 03 0f 5b 00 00  e2 83 4b 5e 65 85 4b 5e  |.....[....K^e.K^|
280020410  65 84 4b 5e 00 00 00 00  64 00 01 00 30 00 00 00  |e.K^....d...0...|
280020420  00 00 08 00 01 00 00 00  0a f3 01 00 04 00 00 00  |................|
280020430  00 00 00 00 00 00 00 00  06 00 00 00 03 42 81 00  |.............B..|
280020440  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
280020460  00 00 00 00 43 37 97 1e  00 00 00 00 00 00 00 00  |....C7..........|
280020470  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
280020480  20 00 00 00 78 9c 6d 2d  fc 6e 49 1f 5c b2 87 eb  | ...x.m-.nI.\...|
280020490  e2 83 4b 5e 5c b2 87 eb  00 00 00 00 00 00 00 00  |..K^\...........|
2800204a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
И похоже пока перегрузился, а исследуемый блок уже занят другим inode - но, возможно, это система что то там переместила в процессе проверки. И, кстати, убеждаемся в части упомянутых выше 24 байт.

Как то так, может кому и пригодится - не обязательно для этих целей, но возможно для … не хороших дел (например, изменения даты) … или получения дополнительной информации.

EDIT 1 - Уточнение, разумеется, если уж заупрямится обнулить debugfs, то это всегда можно выполнить в ручную, прямо на диске ...

EDIT 2 - .... и еще раз напоминаю, в режиме write, будте внимательны и осторожны - You may completely destroy the data on your hard disk!
Ошибки не исчезают с опытом - они просто умнеют