chris wrote: > Hi, > > > I'll go on record repeating the comments made earlier. deleting the > > students largest file is probably deleting their most important > > work. > > Of course, it should be only a last resort; I tried to make that clear. > I hope that in 8.2 we'll fix the problem in general, in a way that > prompts for which files to delete. This patch would be an interim > workaround for deployments to ameliorate the current problem of > non-booting laptops, and a failsafe for any edgecases we miss in 8.2.
it sure feels as if adding a time component to the "nuking" algorithm would help (e.g. something based on "du -s $(ls -rtd PATH/*)"), but i guess it wouldn't, really. can we at least nuke some obvious big (or otherwise useless-in-a-deployment) installed files first? that's only a one-time thing, but it's arguably better than losing "real" data. ben wrote: > This hackish approach is meant only as a patch to existing systems running > old builds. Uruguay has a comprehensive system for deploying such patches > quickly. Based on our new understanding of the urgency of the full NAND is it really true that uruguay can deploy patches quickly? then surely we can come up with a simple cron-based script that puts a large-font warning in an xterm when diskspace is low? it would (obviously) be ugly, but still better than a failed boot and loss of data. if the diskspace disappears all at once, due to downloads or something, then this won't help, but i'll bet we could choose a threshold that would be successful pretty often. we might even cause it to run more often when browse or record is running. paul =--------------------- paul fox, [EMAIL PROTECTED] _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
