Prevent a file from being sent to "archive"?

Discuss anything specific to using Puppy on a multi-session disk
Post Reply
Message
Author
nduanetesh
Ultra Super-stud
Posts: 168
Joined: Fri 06 May 2005, 02:36

Prevent a file from being sent to "archive"?

#1 Post by nduanetesh »

Ok, now that I've got a multisession puppy Cd working on my laptop, I've encountered a small problem.

I installed firefox, and using the -D option in the rc.reboot file, everything burns and restored correctly, *except* for one little problem...

The file "firefox-bin", which is the actual firefox browser, I think, is over 5MB in size, so at the end of every session, it gets moved to the "archive" folder on my newly burned session and is not restored on the next boot. So, I have to mount the CD and copy the file before I can use firefox. Is there a way to prevent a file of over 5mb from being moved to "archive" at the end of the session?

ND

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#2 Post by BarryK »

Hmmm, looks like I'll have to modify the shutdown script....
maybe make it something real big like 10M, anything over 10M gets moved to archive.

nduanetesh
Ultra Super-stud
Posts: 168
Joined: Fri 06 May 2005, 02:36

#3 Post by nduanetesh »

HI Barry,

The file in question is 9557K, which would be OK with a 10MB limit. However it seems to me that leaving everything under 10MB out of the archive folder would pretty much guarantee that not much of anything ever got sent to "archive". Other than video files, I don't think I have many files at all on my hard drive that are over 10MB. Would it be possible to leave the 5MB limit in place, but create some sort of special folder, the contents of which are never sent to "archive"? Then a user would have the option of either doing the install of large programs into that folder, or in this case I could put the firefox-bin file into this folder and create a symlink to it in my firefox directory. Is it possible? Would it be difficult to implement?

ND

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#4 Post by BarryK »

Well, I think I'll just make the size limit over 10M.
I think the shutdown code does move .tar.gz and .tar.bz2 files into /root/archive, of any size, which is probably more important to clean up.

nduanetesh
Ultra Super-stud
Posts: 168
Joined: Fri 06 May 2005, 02:36

#5 Post by nduanetesh »

Hey Barry,

Did you forget to implement this change in puppy 1.0.4? I'm still getting the "the following files will be moved to "archive"" message. And my rc.reboot-cd file still has the file size limit of "5000k". I've tried to edit rc.reboot-cd by hand and change it to "10000k", but it has no effect at shut down. anything over 5MB is still moved to archive. So, I still lose firefox-bin every time (which, just as a little reminder, is 9557k. So a limit of 9000k in rc.reboot-cd won't quite be enough.)

ND

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#6 Post by BarryK »

Hmm, okay, maybe it is a problem with the /etc/rc.d/rc.reboot-cd file.
The latest one from the CD is not being used.

The file should have a modify date of 16 July.

If it is the wrong file, you could rename it or delete it, then
change /etc/puppyversion back to 103, then reboot.

The latest should then load.

nduanetesh
Ultra Super-stud
Posts: 168
Joined: Fri 06 May 2005, 02:36

#7 Post by nduanetesh »

Yeah, Barry, that was the problem. I have no idea how it happened, though, as I booted a brand new puppy 1.0.4 CD and didn't upgrade from my previous CD...I did, however, mount the previous CD to copy the firefox installer from it...maybe I inadvertantly screwed something up during that time (like trying to reboot with the old CD inserted?).

Anyway, I made a new 1.0.4 CD and booted from it, didn't do an upgrade or anything (even downloaded firefox anew) and everything is working great. Firefox-bin doesn't get archived, and long filenames are no longer a problem.

Great work, Barry!

ND

Post Reply