Puppy Linux Discussion Forum

Just need a hand please.

I have a file in sylpheed mail folder in trash that refuses to get deleted .
Here is some of the stuff I have tried to find out why it is different . Any suggestions?

Hello,
I don´t use email apps in Puppy, so I don´t know the consequences of deleting that file.

Anyway, to delete anything I would try to delete the file "from outside" (I would boot with pfix=ram (or boot into another puppy), then navigate inside the savefolder where the file resides and try to remove it).

It would be good to do the backup of the savefolder before this.

@April :-

Never used Sylpheed in anger! I tried it once, but honestly, it is such a PITA to set up correctly - all has to be done manually, from what I recall - that I've always stuck with Thunderbird. Which just works, for me.

I'll second Feek's suggestion, however. Try booting from another Puppy, if you can; then go into the save-file/folder - whichever you have - and delete it that way. Should work....

Mike.

Is the file system ext4? I think ext4 is more buggy than ext3. In any case, this bug has happened a few times before.

It behaves exactly like a symlink to a file after that file has been deleted, and the symlink is still there.

# echo aaa > aaa
# ll aaa bbb
-rw-r--r-- 1 4 Oct 11 14:08 aaa
lrwxrwxrwx 1 3 Oct 11 14:08 bbb -> aaa
# 
# cat bbb
aaa
# 
# rm aaa
# ll bbb*
lrwxrwxrwx 1 3 Oct 11 14:08 bbb -> aaa
# cat bbb
cat: bbb: No such file or directory
#

I think what may be happening, is that the inode in the virtual file system's directory is unlinked, but the file name is still in the directory of file names, The opposite is very common, when the file name is unlinked but the inode is still in the file name directory. fsck can fix that easily. It doesn't seem to try to fix an orphaned file name.

you can try:

1) booting Puppy with the boot parameter pfix=fsck

2) booting another Puppy or booting puppy with pfix=ram (so that the save file/folder is not mounted) and running fsck.ext4 -fp dev-name and fsck.ext4 -fy dev-name (or fsck.ext3)
-p and -y seem to behave slightly differently.
dev-name would be the name of the save file, or the partition that the save folder is on, eg. /dev/sda1

3) you can try debugfs dev-name. Again, the save file or folder should be not mounted.
When debugfs is running, you can type help
you want to find the file in the file system, then unlink the name of the file. Useful commands:
cd
ls
rm
kill_file
unlink
clri
help
quit

Be careful using debugfs. If you save a backup, if the save file gets badly corrupted, you can copy back the backup file.

You should do a fsck after using debugfs.

Another thing you can try, that is very simple:

echo xxx > 105

This should save data to the file, which requires an inode, so you would have a file name and an inode pointing to the file system's data blocks.

So the file name should be linked properly to data, and hopefully, it would work.

it's worth a try.

williams2 wrote: ↑Mon Oct 11, 2021 7:36 pm

Is the file system ext4? I think ext4 is more buggy than ext3. In any case, this bug has happened a few times before.
No its ntfs

1) booting Puppy with the boot parameter pfix=fsck Didn't change anything.

2) booting another Puppy or booting puppy with pfix=ram (so that the save file/folder is not mounted) and running Didn't change anything.

3) you can try debugfs dev-name. Again, the save file or folder should be not mounted.Yet to look into this Will try

Thanks

williams2 wrote: ↑Mon Oct 11, 2021 8:25 pm

Another thing you can try, that is very simple:

echo xxx > 105

This should save data to the file, which requires an inode, so you would have a file name and an inode pointing to the file system's data blocks.

So the file name should be linked properly to data, and hopefully, it would work.

it's worth a try.

root# echo xxx > 105
root# echo xxx > 165
root# rm  165
rm: cannot remove '165': No such file or directory
root# rm  105
root# 

So it created 105 OK and removed it but not 165.
What is the "ll" command you used above?

root#  ll bbb*
bash: ll: command not found
root# lrwxrwxrwx 1 3 Oct 11 14:08 bbb -> aaa
bash: lrwxrwxrwx: command not found
root#  ll aaa*
bash: ll: command not found
root# rm  165
rm: cannot remove '165': No such file or directory
root# lrwxrwxrwx 1 3 Oct 11 14:08 bbb -> 165
bash: lrwxrwxrwx: command not found
root# echo here is some data xxx > 165
root# touch 165
root# cat 165
here is some data xxx
root# 
root# 
Wierd ?

No its ntfs

Oh, that's different. None of those things that I suggested will work, they are for linux ext file systems.

If you are having a problem with an ntfs file system, you should try the MS WIndows repair tools, like chkdsk.exe

If you don't have Windows, you can try ntfsfix . For example if the ntfs file system is on /dev/sdb2;

ntfsfix /dev/sdb2

ntfsfix does not work as well as chkdsk,exe

What is the "ll" command you used above?

I wrote a script named ll

#!/bin/ash
ls -goh "$@"

Most people would make ll an alias. I prefer it as a script.
For me, ll is the same as typing ls -goh

Wierd ?

Yes, definitely weird. I know that linux ext files systems will do that sometimes.

This has nothing to do with your untrashable file, but just to clarify two things I saw in your screenshot in the original post:

A) ".." is shorthand for "the directory one level up from the current working directory". So if you are in say /root/my-applications, then ".." is short for "/root"

Since ".." just names a directory, it's not an executable command by itself. You'd use it with something like "cd"

root# cd ..

means go up one level to the parent of the current directory.

B) "." when used where a directory name is expected is shorthand for "the current working directory." For example

root# ./someapp

would run the executable named 'someapp' found in the current directory--as opposed to say a different executable also named 'someapp' that might exist elsewhere in your PATH.

On the other hand,

root# . somefile

would read the text file 'somefile' and execute the commands found therein, just as if you had typed them in manually. The assumption is that "somefile" is a shell script of some kind.

6502coder wrote: ↑Mon Oct 11, 2021 9:53 pm

A) ".." is shorthand for "the directory one level up from the current working directory". So if you are in say /root/my-applications, then ".." is short for "/root"
Since ".." just names a directory, it's not an executable command by itself. You'd use it with something like "cd"
root# cd ..
means go up one level to the parent of the current directory.
B) "." when used where a directory name is expected is shorthand for "the current working directory." For example
root# ./someapp
would run the executable named 'someapp' found in the current directory--as opposed to say a different executable also named 'someapp' that might exist elsewhere in your PATH.
On the other hand,
root# . somefile
would read the text file 'somefile' and execute the commands found therein, just as if you had typed them in manually. The assumption is that "somefile" is a shell script of some kind.

Yes just mucking around throwing anything at it to see the effect.!

I suspected as much! Well, hopefully someone else might have learned something new...

Research
Please provide the output from the following

whoami
mount | grep TempSaveKenny
lsof /mnt/home/TempSaveKenny/Mail/trash/165
ls -lh /mnt/home/TempSaveKenny/Mail/trash/165
ls -i /mnt/home/TempSaveKenny/Mail/trash/165
file /mnt/home/TempSaveKenny/Mail/trash/165 ~/165
cp /mnt/home/TempSaveKenny/Mail/trash/165 ~/165.duplicate
rm ~/165.duplicate

Possible Issue
If the partition is on a flash drive, the flash drive might be going bad. Sometimes when they do, files will be read only, and there is no way to make them writable

Partition Check and File Removal

• Boot up Windows, and run a chkdsk/scandisk on the partition. Try to remove the file from Windows

• run Puppy Linux completely in RAM (ie pfix=ram). Use GParted to check the partition

Don't ever use windows
left that behind in 2003 when microsoft and google tried to control me.

Done all the puppy stuff
The code is a bit too intrusive . Ill give you the last bit though.

root# ls -lh /mnt/home/TempSaveKenny/Mail/trash/165
-rwxrwxrwx 1 root root 22 Oct 12 06:40 /mnt/home/TempSaveKenny/Mail/trash/165
root# ls -i /mnt/home/TempSaveKenny/Mail/trash/165
32153 /mnt/home/TempSaveKenny/Mail/trash/165
root# file /mnt/home/TempSaveKenny/Mail/trash/165 ~/165
/mnt/home/TempSaveKenny/Mail/trash/165: ASCII text
/root/165:                              cannot open `/root/165' (No such file or directory)
root# cp /mnt/home/TempSaveKenny/Mail/trash/165 ~/165.duplicate
root# rm ~/165.duplicate

You probably know, but just to be sure. Don't try to remove the file while its in memory. File-browse to it on your drive. You should be able to Right-Click>Delete.

Time for another round of tests

find /mnt/home/TempSaveKenny/Mail/ -inum 32153 -delete

From the look of things "/mnt/home/TempSaveKenny/Mail/" is in a SaveFile. Puppys mount SaveFiles creating links in RAM to the files in the SaveFile. The command "find /mnt/home/TempSaveKenny/Mail/" examines the /Mail folder after copying it into RAM.
I may be wrong about the third part, but know the first two parts of the following are correct. (1) You can access the contents of a SaveFile by Left-Clicking it. That mounts it, but does not create the links mentioned above. (2) You can then file-browse into it and examine the contents of the /Mail/trash folder. (3) You should then be able Right-Click the "165" file and select Delete.
What may have happened is that one of your prior attempt to delete it just "whited-it-out". While part of your operating system a whited-out file can not be seen by your system. A SaveFile mounted by Left-Clicking is not part of operating system.
Of course, the above may be wrong. I'm just working by analogy. I have a problem with one of my SaveFile. Whenever I execute a Save, the /root/.thumbnails/normal folder gets whited out so right-clicking rox's 'Eye' no longer shows thumbnails. Examining the .thumbnails folder in a mounted SaveFile shows that a ".wh" file is adjacent to the 'normal' folder. Puppy can not see the ".wh" file in RAM. But it is a system file and has the effect of preventing Puppy from using the /normal folder. Deleting the .wh file from the mounted SaveFile returns /normal to Puppy and Puppy to normal. Thanks, again, williams2.
If you find a .wh file adjacent to either /trash or "165", delete it. You don't have to boot puppy pfix=ram, or I think even reboot after deleting. Menu>Exit>Restart-x (AKA graphic-server) may be sufficient.

I have had a related problem, mikeslr is touching the subject. My tahr64 would not show thumbnails, and the folder named /root/.thumbnails/normal was inaccessible. I could not delete it, I could not move it, everything was denied, I also tried to manipulate the save file, I asked this forum, but nothing worked. In the end I made a new folder in /root/.thumbnails, named Normal (with a big N). And suddenly, the red marked and inaccessible normal disappeared. I renamed the Normal folder to normal, and suddenly I have thumbnails again.
April, maybe an atempt to create a similarly named file in the same place, may solve your problem?

tallboy

This is not the first time that someone had a broken .thumbnails dir. I suggested some things to try if it is an ext file system, but they won't work with an ntfs file system.
I asked the OP specifically and the OP said it was an ntfs file system.
If the file system is in a save file or save folder, it is unlikely to be ntfs.

I'm not sure, but I suspect that this is an ext4 bug.
I suspect the problem is an orphan file name (a name with no inode) in the virtual file system, which fsck does not seem to fix.
Fsck easily deals with the opposite problem, an orphaned inode. (an inode with no file name)

williams2 wrote: ↑Sat Oct 30, 2021 1:20 am

I asked the OP specifically and the OP said it was an ntfs file system.
If the file system is in a save file or save folder, it is unlikely to be ntfs.

Sometimes I wonder at peoples assumptions frankly