Chacham's Journal: rm mv

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

[keesh]

You need a VAX.

Re:Simple

[Chacham]

I used VAX/VMS at a university. The versions of file are cool, but rather confusing.

I am using Linux, so I'd a like a system to work with it.

Re:Simple

[keesh]

Yeah... Ages back I wrote some almighty hack for some database system to do pretty much what you were describing... Records (and tables, for that matter -- wow that was messy) had a date field that was set every time the record was modified. That was easy enough to do. Then there was a cron which got rid of old stuff every so often.

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 /etc/passwd gets accessed about once a week when I have to su to root, other than that it's left alone. Wouldn't want that deleted though...

Re:Simple

[Chacham]

Well, in order for a file to get into the system/table, you'd have to run a command. That is, instead of rm, you use ddmark (date-delete mark), or whatever.

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

[huckda]

I haven't checked and don't feel like ssh'n to my server to check, but maybe a simple -d flag for the 'rm' command(dunno if there is already a -d option). rm -d to 'mark a file for deletion as space is needed'
and thus that file would 'disappear' but only be RM'D as space became a precious commodity.

--Huck

Never mind...rm -d

[huckda]

it exists and is to remove (unlink) a directory even if it is unempty...
hell and I've been use'n

rm -rf all these years :)

--Huck

Re:ddrm

[Chacham]

-d, --directory attempt to unlink target, even if non-empty (super-user only)

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

[sir99]

See chattr(1), specifically the "u" attribute. Unfortunately, as with most of the attributes mentioned on that page, it looks like this still isn't implemented on Linux. The idea is there anyway. Maybe you'd like to implement it in 2.5? I'm sure others would appreciate it :-)

Re:chattr

[Chacham]

As I really have never coded in C, I'd be afraid to touch a filesystem command myself.

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.