"files" that can't be deleted
"files" that can't be deleted
I googled and found this thread, but unfortunately no solution. I'm having a very similar problem. I have a directory filled with these "files", which rox filer labels with orange exclamation point danger sign icons. They don't seem to take up any space, but I can't change the permissions on them or delete them--either from rox filer or from the terminal. I've tried in three different linux distros now, and none of them seem to be able to affect these things. When I open up a properties window, it shows "Error: input/output error", which is the same error I get from rox filer and from the terminal when I try to affect them in any way. It also shows a completely blank permissions table.
What does this mean? Is my hard drive going bad?
What does this mean? Is my hard drive going bad?
Re: "files" that can't be deleted
Hello Saladin.Saladin wrote:I googled and found this thread, but unfortunately no solution. I'm having a very similar problem. I have a directory filled with these "files", which rox filer labels with orange exclamation point danger sign icons. They don't seem to take up any space, but I can't change the permissions on them or delete them--either from rox filer or from the terminal. I've tried in three different linux distros now, and none of them seem to be able to affect these things. When I open up a properties window, it shows "Error: input/output error", which is the same error I get from rox filer and from the terminal when I try to affect them in any way. It also shows a completely blank permissions table.
What does this mean? Is my hard drive going bad?
Could be...
Are you getting a "stat" message as well? Something like: "cannot stat file
or directory so-and-so."
However, before myself or anybody else here can help you, please state breed
and version of your PuppyLinux and a short description of your PC, and in this
case, of your hard drive, too.
A few questions:
Is your HD really old?
What is the format of the HD? ext2, ext3, ext4,vfat, ntfs?
As mentioned in the other thread, do you have a recent back-up?
If the file system is ext-something, maybe it just needs a refresh with the
fsck utility.
If ntfs, then use the equivalent WhineDose utility, defrag or something.
But please provide requested info before we can go further. TIA.
IHTH.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
These could be: files that do not exist; links to files that do not exist anymore or incorrect links to files that still exist. Anyways - if you are running a savefile you should be able to "delete" these most probably resulting in hiding them from view. If they are part of the base sfs file or any other loaded sfs file, the only way to physically remove them is to edit/remaster that sfs file.
Do they look like this image?
- Attachments
-
- capture8704.png
- (5.61 KiB) Downloaded 221 times
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Yes, they look just like those icons, except they don't have the symbolic link arrow.
I do have a directory with broken links in it, so I can compare them. The broken links say "Sym link 'file'" when I right-click on them. The other files say "Unknown 'file'". The broken links give me lots of information on the properties window, like owner, size, change/modify/access times and so on. The other files just say "Error: input/output error" and give me a blank permissions table. And of course I can delete the broken links.
But the icons are the same between the two, and both have the red letters instead of the usual black.
I haven't seen any "cannot stat" message, but maybe I'm not looking in the right place.
I've seen these icons on Xenial 64 7.5, 32 bit Precice , and on Tiny Core--they don't seem to be tied to the OS, just the hard drive. The hard drive is about ten years old, and formatted as ntfs.
I do have recent backups of everything irreplaceable, but there's more than 200 gigs that isn't backed up that I'd rather not lose if I can avoid it.
I do have a directory with broken links in it, so I can compare them. The broken links say "Sym link 'file'" when I right-click on them. The other files say "Unknown 'file'". The broken links give me lots of information on the properties window, like owner, size, change/modify/access times and so on. The other files just say "Error: input/output error" and give me a blank permissions table. And of course I can delete the broken links.
But the icons are the same between the two, and both have the red letters instead of the usual black.
I haven't seen any "cannot stat" message, but maybe I'm not looking in the right place.
I've seen these icons on Xenial 64 7.5, 32 bit Precice , and on Tiny Core--they don't seem to be tied to the OS, just the hard drive. The hard drive is about ten years old, and formatted as ntfs.
I do have recent backups of everything irreplaceable, but there's more than 200 gigs that isn't backed up that I'd rather not lose if I can avoid it.
unmount the ntfs drive and then in a terminal try:
replace the /sda1 with your drive.
did this change anything?
Code: Select all
/sbin/mount.ntfs-3g /dev/sda1 /mnt/sda1
did this change anything?
If you can boot Windows.
Use Windows defrag and chkdsk programs on the ntfs partition.
See if they find and correct anything in the ntfs file system.
Could try a check of the save.
To test for and repair errors in Linux file system, use "e2fsck".
Reboot Puppy, using boot option " puppy pfix=ram"
The save file can not be in use.
Mount the partition the save is on.
Open a terminal, and enter:
e2fsck /path to savefile
For example:
e2fsck /mnt/sda1/pupsave.2fs
/mnt/sda1 is the partition the save is on.
pupsave.2fs is the name of the save.
Yours will be different names.
Use Windows defrag and chkdsk programs on the ntfs partition.
See if they find and correct anything in the ntfs file system.
Could try a check of the save.
To test for and repair errors in Linux file system, use "e2fsck".
Reboot Puppy, using boot option " puppy pfix=ram"
The save file can not be in use.
Mount the partition the save is on.
Open a terminal, and enter:
e2fsck /path to savefile
For example:
e2fsck /mnt/sda1/pupsave.2fs
/mnt/sda1 is the partition the save is on.
pupsave.2fs is the name of the save.
Yours will be different names.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Hello Saladin.
Do these files have names? Please mention them if you can.
That could give us a clue as to what type of files they are:
From WhineDose OS?
From Linux OS?
Document files?
Executables?
Libraries?
TIA
I once had the exact same problem after formatting an USB key in UDF. A
couple of files appeared from nowhere, and I was not able to erase them.
The only solution was to reformat the key in ext2. (Just a thought.)
BFN.
Do these files have names? Please mention them if you can.
That could give us a clue as to what type of files they are:
From WhineDose OS?
From Linux OS?
Document files?
Executables?
Libraries?
TIA
I once had the exact same problem after formatting an USB key in UDF. A
couple of files appeared from nowhere, and I was not able to erase them.
The only solution was to reformat the key in ext2. (Just a thought.)
BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
If everything is working.
Stop looking at those files.
If it is not broken stop trying to fix it.
A file system check may correct this.
Probably some fragments in the file allocation table in the file system.
Stop looking at those files.
If it is not broken stop trying to fix it.
A file system check may correct this.
Probably some fragments in the file allocation table in the file system.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
No, it doesn't seem to have changed anything.rockedge wrote:unmount the ntfs drive and then in a terminal try:replace the /sda1 with your drive.Code: Select all
/sbin/mount.ntfs-3g /dev/sda1 /mnt/sda1
did this change anything?
Don't have Windows or a save file. The files are on the actual hard drive.bigpup wrote:If you can boot Windows.
...
Could try a check of the save.
I don't use a save file for booting Puppy. Instead, remastered with a symlink to the hard drive for wine to save its "drive_c" files there. I recently upgraded to a new version of Puppy, and deleted the old "drive_c" directory--except that some of the files inside didn't go away. They're named: "America" and then there's a directory named "Africa" with the following inside:musher0 wrote:Do these files have names? Please mention them if you can.
Malabo
Maputo
Maseru
Mbabane
Mogadishu
Monrovia
Nairobi
Ndjamena
Niamey
Nouakchott
Ouagadougou
Porto-Novo
Sao_Tome
Timbuktu
Tripoli
Tunis
Windhoek
So it's not a warning sign that the hard drive is going bad, or anything like that?bigpup wrote:A file system check may correct this.
Probably some fragments in the file allocation table in the file system.
Hi Saladin.
Those names are cities in various African countries. Looks like the
leftover of a timezone app.
In any Puppy, have a look at (cd to)
/usr/share/zoneinfo/Africa
Very similar. It's used mostly by the date utility, but also (not 100 %
sure) by the ntp protocol (when its utilities are installed).
But the good news is: they are info (data) files, not executables and
certainly not malware.
Maybe the leftover from a incomplete formatting or partitioning. A power
outage occurred while formatting was going on, maybe? Do you recall
anything like that? If not yourself, perhaps the previous owner of the hard
drive? That would explain it.
BFN.
Those names are cities in various African countries. Looks like the
leftover of a timezone app.
In any Puppy, have a look at (cd to)
/usr/share/zoneinfo/Africa
Very similar. It's used mostly by the date utility, but also (not 100 %
sure) by the ntp protocol (when its utilities are installed).
But the good news is: they are info (data) files, not executables and
certainly not malware.
Maybe the leftover from a incomplete formatting or partitioning. A power
outage occurred while formatting was going on, maybe? Do you recall
anything like that? If not yourself, perhaps the previous owner of the hard
drive? That would explain it.
BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Hello again, Saladin.
Could you please jot down somewhere the complete path of those
zoneinfo files, please?
Then could you please open a console and type:you should get something like this:
name when not mounted, type of format and size.
Look in 1st column, 2nd part: the sdXY part.
Do you have a similar sdXY part in the path of your weird files?
This comparison will tell us the name of the partition and its format.
Also if a fsck from the Linux OS will solve the problem... if it's a
Whinedose partition such as ntfs or even vfat, we may be out of luck.
BFN.
Could you please jot down somewhere the complete path of those
zoneinfo files, please?
Then could you please open a console and type:
Code: Select all
probepart
probepart gives you the raw info about your drives:/dev/sda1|ext4|163840000
/dev/sda2|swap|5120000
/dev/sda5|ext3|59979776
/dev/sda6|ext4|59979776
/dev/sda7|ext3|98981888
/dev/sda8|ext4|80945152
/dev/sdb1|ntfs|15361984
/dev/sdb2|ext4|73728000
/dev/sdb5|ext4|74752000
/dev/sdb6|ext4|74364928
/dev/sdb7|ext4|74362880
/dev/sdc1|none|204800
/dev/sdc2|swap|4096000
/dev/sdc3|ext4|153600000
/dev/sdc5|ext4|153600000
/dev/sdc6|ext3|221184000
/dev/sdc7|ext4|221184000
/dev/sdc8|ext4|222894080
/dev/zram0|ext2|4790272
name when not mounted, type of format and size.
Look in 1st column, 2nd part: the sdXY part.
Do you have a similar sdXY part in the path of your weird files?
This comparison will tell us the name of the partition and its format.
Also if a fsck from the Linux OS will solve the problem... if it's a
Whinedose partition such as ntfs or even vfat, we may be out of luck.
BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
(Sorry for being so wordy!)
About your drive being bad: let's not put the cart in from ot the oxen for
now.
There exists diagnostics software that will tell you which sectors or section
of the HD are (is) bad. And then you can do one partition before the defect
and one partition after -- if you have only one defective part.
But let's not conclude anything for now.
About your drive being bad: let's not put the cart in from ot the oxen for
now.
There exists diagnostics software that will tell you which sectors or section
of the HD are (is) bad. And then you can do one partition before the defect
and one partition after -- if you have only one defective part.
But let's not conclude anything for now.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Definitely looks like the same files. I don't remember it happening, but I could believe that the computer locked up while I was deleting the wine directory.musher0 wrote:In any Puppy, have a look at (cd to)
/usr/share/zoneinfo/Africa
Very similar. It's used mostly by the date utility, but also (not 100 %
sure) by the ntp protocol (when its utilities are installed).
Maybe the leftover from a incomplete formatting or partitioning. A power
outage occurred while formatting was going on, maybe?
It's sda1, ntfs.musher0 wrote:Do you have a similar sdXY part in the path of your weird files?
This comparison will tell us the name of the partition and its format.
Not really worried about it if all it is is the power going off while files were being deleted. As long as there's no risk to the rest of the disk, I'm content to ignore them.
try
Code: Select all
chattr -i -a yourfilename
rm -f yourfilename