Journal Chacham's Journal: rm mv 9
There must be many schemes for not completely deleting files. My main point would be to tag files for deletion, and delete them only as space was needed, in FIFO manner.
I guess I like the idea someone once told me was Novell's way of doing it.
Instead of figuring out how to do it in the current system with all its limitations, I am thinking about expressing it without limitations. Only after the idea is complete, will I try to force it into the current limitations.
It should be easy. I like databases, so imagining the files were in a table, I'd add a field. The field would be a DATE/TIME field, that would mention when it was marked for deletion. A NULL value would mean that it was not marked.
When space was needed, a simple
SELECT Filename, Blocks FROM Files ORDER BY Marked_For_Deletion_Date;
would do.
I guess an algorithym could be added, to say that if a second file needs to be deleted to make enough space for the new file, then maybe it is all that is needed (and file 1 can stay).
A feature could be added to add a priority number (weight) to deletion. That is, a person decides a file isn't needed, but wouldn't mind keeping it around just-in-case. That would be the last file to be deleted.
One big issue with this is the need for proper filespace reporting. Most reporting needs to ignore files that were marked for deletion.
Further, should the marked files be removed from the current directory? Maybe a bit could be used to should that it was marked instead? The idea of using a separate directory is bothersome to me.
Simple (Score:2)
Re:Simple (Score:2)
I am using Linux, so I'd a like a system to work with it.
Re:Simple (Score:2)
The tricky bit was that some stuff had to be based upon read date as well as write date. Fortunately the CPU power and disk speed was there to update an 'accessed' field as well, but it wasn't pretty.
Wouldn't like to do something like that on a filesystem. Have to be very careful about what was expired... On my home system
Re:Simple (Score:2)
The system would also only go actually do anything when the disk was full. Even then, a companion command could be used to do the actually deletion, such as ddrm.
ddrm (Score:1)
and thus that file would 'disappear' but only be RM'D as space became a precious commodity.
--Huck
Never mind...rm -d (Score:1)
hell and I've been use'n
rm -rf all these years
--Huck
Re:ddrm (Score:1)
Good idea though. I am in no way knowledgeable enough to implement it, though I'd be glad to (try to) anyone who would.
chattr (Score:1)
Re:chattr (Score:1)
Although, I would be very much inclined to help design the idea.
And thanx for pointing out the chattr command.
Note, please, that this is not so much for undeletion, as it is for, space reclamation. Undeletion is an aspect of it, but I don't want to address that issue directly. I believe that if a file is needed, it shouldn't be deleted. And then when to dump undeletion to reclaim space is a thorny issue. Besides, undeletion removes the original file from its directory, and I do not want that.
Instead, I think undeletion would be a pretty much moot point with space reclamation only happening as needed. This way, unless you want a file absolutely deleted right now, you just throw it on the stack. Eventually it will be deleted. But first, your disk has to fill up, and then the queue would be traversed in a FIFO fashion.