Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

rm mv

Chacham (981) writes | more than 12 years ago

User Journal 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.

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.

cancel ×

9 comments

Sorry! There are no comments related to the filter you selected.

Simple (2)

keesh (202812) | more than 12 years ago | (#3729158)

You need a VAX.

Re:Simple (2)

Chacham (981) | more than 12 years ago | (#3729446)

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 (2)

keesh (202812) | more than 12 years ago | (#3729823)

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 (2)

Chacham (981) | more than 12 years ago | (#3730048)

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 (1)

huckda (398277) | more than 12 years ago | (#3811513)

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 (1)

huckda (398277) | more than 12 years ago | (#3811547)

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 (1)

Chacham (981) | more than 12 years ago | (#3812037)

-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 (1)

sir99 (517110) | more than 12 years ago | (#3729821)

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 (1)

Chacham (981) | more than 12 years ago | (#3730148)

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.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>