On Sun, Feb 13, 2005 at 08:38:58AM +0100, Goswin von Brederlow wrote: > Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > > > On Sat, Feb 12, 2005 at 07:47:40PM +0100, Jeroen van Wolffelaar wrote: > >> My mirror was running a bit out-of-diskspace, that I took a look at > >> where this space went. I turns out, that debmirror doesn't cleanup > >> properly. > >> > >> For example, I have pool/main/k/kernel-patch-2.4.25-mips and kvim on my > >> mirror, but that source package was removed from unstable in october > >> resp. november 2004. > > > > Ah, I find the issue here, debmirror uses 'find', but due to space > > constraints, part of my mirror were on other partitions, and symlinked > > to there. > > > > find doesn't follow symlinks, so there it goes wrong. > > Try adding "-follow" to the find call and run with --dry-run. I fear > that adding -follow will remove /dists/unstable/* and /dists/testing/* > though if you have those thinks, so --dry-run it.
You're correct -- that would have removed almost all of dists via symlinks if I didn't have hadded --ignore=^dists, but otherwise it works. I'm unsure what the best course of action would be here, find doesn't have an option of 'follow symlink if pointing outside of $ftproot' afaik. Otoh, this issue is mostly only relevant for pool, as dists is not so easily splitteable outside of $ftproot via symlinks. I can't fink of a clean solution to this problem that would work, unless dists is handled special. I think it's best left up to you as author/maintainer to decide whether or not you think this handling would outweigh the hackiness, or whether you can find a non-hackish solution. (doing this only for pool, and regular find for dists? Add the symlinks in the top level of dists to a 'recursive ignore' for removal purposes?) --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
