I had a comic packed in rar format and opened it with comix.
For some reason I decided I no longer needed it and deleted the file permanently, along with comix directories inside .config and .local/share. But I late realized that I had never closed comix program!!
Not again, another **** mistake!? Though I noticed the only file reapearing was oen named recently-used.xbel inside .local/share…
Any harm to comix program or OS itself?
nope nothing I can think off
Thanks.
But just in case, any other more elaborate point of view by chance? Thanks.
I already rebooted Leap several times, fearing I’d have to reinstall…
On 11/10/2017 11:36 AM, F style wrote:
>
> Thanks.
>
> But just in case, any other more elaborate point of view by chance?
> Thanks.
> I already rebooted Leap several times, fearing I’d have to reinstall…
>
>
The only thing you have to fear is yourself for being overly paranoid.
In other words nothing is broken.
–
Ken
linux since 1984
S.u.S.E./openSUSE since 1996
What if there’s some certain “dead” amount of used storage still remaining that cannot be purged, or the like, as a consequence?
Or some invalid soft/hard link somewhere?
Or there’s nothing like that?
I have been using openSUSE for some few years already, but I’m still a complete noob
This is what I’ve personally found over the years…
If you do a file operation in a console using command line, there is an extremely high certainty that there are no orphaned files or pointers.
When you do some operation at a higher level like what you seem to have done, yes you can have orphaned files and pointers.
Generally speaking, the best you can do is to research the file integrity checks specific to the file system installed (BTRFS? EXT4? XFS?) and run whatever scans and possible repairs might be possible. You can also try running forensic apps like photorec, but I wouldn’t generally recommend that… File operations on inodes with weird names have a much higher chance of an irrecoverable error.
IMO,
TSU
Wait, what the heck?
the answer to your question about deleting comix config files while comix is still opened is no nothing bad can happen to your OS or comix
worst case scenario as comix is still open it will recreate it’s config files when it’s closed so the file you deleted will be restored
I don’t get the rest of your questions there are very few if any hard links used in config files in your home ~
if you’d like to cleanup your profile folder a safe-ish way to do so is with BleachBit afaik it does not clean comix settings but it will clean your browser cache and history as well as desktop history it usually recovers a giga byte of data when I run it (that recovered space gets refilled as most of it is browser cache)
zypper in bleachbit
https://software.opensuse.org/package/bleachbit
maybe be more precise about what you want to know
That’s completely harmless.
Some programs deliberately do that. They create a temporary file, and then delete while keeping the file open.
You need to remember that, in unix (and linux), deleting a file only deletes the directory entry. It does not delete the disk space allocated to the file.
A file is identified by an inode (meta-data on disk). The directory entry gives the inode for the file.
Deleting a file deletes the directory entry.
The kernel frees the disk space, when there is no longer an accessible inode referencing it. An inode is accessible if it is in a directory entry or if is in the kernel list of active inodes.
The effect: You delete a file that is still open. The file cannot be accessed via the directory. A program that has the file open can still read and/or write to it (depending on open mode). Once the program terminates, the disk space is freed and the inode is zeroed. If more than one program had the file open, then it is when the last such program terminates of closes that open file, that the disk space if freed and the inode is cleared.
(more than you ever wanted to know about unix file handling).
Le 13/11/2017 à 03:46, nrickert a écrit :
> than one program had the file open, then it is when the last such
> program terminates of closes that open file, that the disk space if
> freed and the inode is cleared.
and it’s a trap 
say you open an openSUSE dvd iso in a virtual machine, then forget it
you may “remove” the disk, still not freeing any space because the dvd
is still opened
I once spent most of a day trying to free space
jdd.
now you’re just blowing bubbles maybe a mod should move this to the soap box
I haven’t run into that specific problem.
Rather more common: Someone runs a program in an extensive logging mode. The “bind” DNS server is sometimes run that way.
Then they notice that the disk is almost full. They see the gigantic log file, and delete it to free up space. But the space is not freed up as long as the same program is running. And if they then try “du”, it does not show the deleted file, so the disk space usage seems to not add up.
Sometimes true, not always.
There was that big Forum thread months back where wolfi and I had that big tug of war on exactly this subject.
Turns out on close inspection there is a fie that contains all the supported file operations by each and every supported file system, and on close inspection some file systems don’t create that temporary file and simply stream the bits, in those cases a dirty, uncompleted file operation might be subject to corruption on both ends (source and destination).
TSU