Re: [Rule-list] vacuum example

[Eugene Wong]

> From: Martin Stricker <address@hidden>
>
> Eugene Wong wrote:
<snip>
> > Therefore, I'll try to make Vacuum move the file and its directory
> > names to /var/spool/
> >
> > For example:
> > address@hidden root]# ls /var/spool/
> > cron  locate  mail  vacuum
> > address@hidden root]# ls /var/spool/vacuum/
> > usr/
> > lib/
> > usr/
> >
> > To see the files & directories for deletion, the user has to enter
> > into these directories, or list the subdirectories. Perhaps the
> > easiest way is to use "locate spool/vacuum".
>
> Idea: Rename /var/run/vacuum.tmp_lst to /var/spool/vacuum/todo.list
> and keep the list of things that were moved here in there. Then a
> vacuum --empty would do something like
> cd /var/spool/vacuum
> rm -rf *
> touch todo.list

I'm not sure that I understand the value of this list. Wouldn't it be better 
to just use "locate spool/vacuum"? After we clean out /var/spool/vacuum/, 
then we could just use updatedb. 1 advantage is that we don't have to worry 
about parsing another file. What advantages does todo.lst have?

> > After that, the user can eliminate at his convenience. An interesting
> > thing that may need to be considered is making the directory secure
> > so that _only_ files & directories from the local system can be sent
> > there.
>
> Hmmmm... that would require vacuum to check with the output of mount
> before doing anything, right? Or is there another way? Maybe vacuum
> should be restricted to ext2/ext3 filesystems, so no one ruins a Windows
> installation? Oh well, why care... ;=D

Yeah, we shouldn't care! :^) After trying out the scripts this afternoon, I 
found out that it's difficult for me to get the script to allow a 
non-root-user to move things into a /var sub-directory. I'm sure that it 
isn't hard, but now that I really think about it, non-root-users shouldn't 
be deleting files like that. If we require the user to be root, then we pass 
on all of the resposibility to him. It seems to solve all security problems. 
If they complain, then we can say, "You shouldn't be deleting!".

This also reminds me of the file lists that you & Marco recommended. I think 
that something like that gets really complex. I believe that that type of a 
feature should be dealt with by another script. The more that I think about 
it, the more I would like to keep this project extremely small. It's basic 
goal should be to just help a person do what he already normally does, but 
do it faster. Adding features should help him, & not burden him. I think 
that if we add too many safety checks here & there, then the user's 
expectations begin to rise, & then we must take on more responsibility.

The spool idea is good, because it helps us to test out the system without 
those files, & yet we don't actually have to delete them.

If Vacuum has to be rpm aware, then all of a sudden, Vacuum becomes less 
portable & more difficult to test. What happens if packages become less 
bloated but we still have records of the old packages? To make a good set of 
lists, we have to make a very intelligent script. What happens if rpm takes 
on a different standard? Then we have to rewrite the script to handle both 
standards. What about Debian users? When RH 38.2 comes out, there will be so 
many file lists that the lists will become bloated. It all becomes a big 
headache to just save approx. 100 MB. I realize that people are on fixed 
budgets, & can't buy hard drives, but that is the responsibility of the 
package maintainers, not RULE or Vacuum. I don't want to spend time trying 
to figure out what I & other users will need. There's just no way for me to 
figure out how many emacs files are not needed & with whom they are not 
needed. That just takes too much energy.

If you would *really* like to build lists of these files in packages, then 
we should make a specific script to handle that. In fact, we may want to 
make a full binary to deal with it. If you are absolutely sure about this, 
then I would recommend that somebody just start with pseudocode.

<snip>
> > To send the files to /var/spool/vacuum/ and restore them, I would
> > like to have the script just make use of mv. It seems so much easier
> > to have the script do "mv usr/lib/locale /" in order to restore the
> > directories & files.
>
> Danger, Will Robinson, danger! ;-)) I have a bad feeling with this,
> blindly overwriting a whole directory tree... And I want to be able to
> `vacuum -r qwertz` (because that's the German keyboard ;=D ), and thus
> restore my keyboard, without stating the complete path, and without
> restoring all those other keyboards and other stuff that I prevacuumed
> before. Yeah, I'm lazy... ;=D I think the todo.list would be convenient
> for this, and to manually took up what's still to be erased.

You shouldn't have to state the complete path with my suggestion. Vacuum 
should be able to look at /var/spool/vacuum/path/to/keyboard/layouts/qwertz 
and realize that qwertz belongs to /path/to/keyboard/layouts/  It should be 
able to figure this out by removing "/var/spool/vacuum/" from 
"/var/spool/vacuum/path/to/keyboard/layouts/".

It should be easy for the user to restore 1 or 2 files, but it will be 
extremely difficult to restore a large portion of them. /usr/lib/locale/ 
would be a real pain to restore if you decided restore half of them in no 
particular pattern. This is like a real vacuum, in that once you suck it up, 
you could still retrieve it, but it will be *very* tedious. Vacuum is only 
good for files & directories that have a 90-100% certainty of being useless. 
strip has no safety checks at all. I think that vacuum should be just like 
strip. I think that there will be so few people using small hard drives 
[500MB or less], that it wouldn't be worth our time to make it featureful. 
On top of that, people are making smaller & smaller packages: uclibc, 
tinygcc, TinyX. This means that there are even less people in need of saving 
space.

Also, building up your own personal /var/db/vacuum.lst file should be done 
slowly over time. Vacuum should be a tool for advanced users, or just users 
who don't care.

To help reduce risk, we could try building a script that analyses the names 
of the scripts, and asseses the amount of risk involved. It could give an 
alert when certain flags have been set. If the user decides to follow 
through, it could call Vacuum, & pass the file name as an arguement.

> > To permanently delete the files, the script could just "echo
> > usr/lib/locale>>[permanent config file]", then do "rm -rf
> > /var/spool/vacuum/usr/lib/locale/". Any other files & directories in
> > /var/spool/vacuum/usr/lib should remain.
>
> Sounds good - just give me the chance to erase only parts of that
> directory, but restore others (which could be done earlier).
<snip>

I've thought about this some more. I don't understand how we are supposed to 
simplify the deletion process. Maybe there could be a script that is only in 
charge of cleaning out /var/spool/vacuum/ & its subdirectories. Maybe the 
cfg file can indicate when to clean these files out. For example, if I 
vacuum .../locale on Monday, & vacuum .../i18n on Wednesday, then the 
following Monday, the script will remove all files & directories 1 week old. 
.../locale will be gone, but .../i18n will still be there. Maybe the cfg 
file can allow root user to decide what to do, by causing the script to 
prompt him.

To summarize this email, Vacuum is not meant to help you learn what to 
delete, or decide what to delete. It only helps you delete what you already 
know is deletable, & compensate. Any other features can be a seperate 
project.


Sincerely, and with thanks,
Eugene T.S. Wong

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail