On Saturday 12 February 2011, Rene Engelhard wrote: > On Sat, Feb 12, 2011 at 06:54:22PM +0100, Stefan Fritsch wrote: > > On Saturday 12 February 2011, you wrote: > > > And what do people store in /share and /user? > > > > /share is a common name for additional file systems (e.g. remote > > NFS shares). You cannot assume that just because a dir is not in > > the FHS, people don't use it. > > Ah, yeah, that. We use someting else, so I ddidn't think that > /share is that commonly used. > > Sorry for that.
Having to restore 30GB from backup is annoying, but at least I have a backup :-/ > > > And you hopefully suggest an alternative way to me how to clean > > > up those broken directories? > > > > Delete the files and directories you have created one by one, > > without -r. > > Probably feasible for /share/config/javasettingsunopkginstall.xml > but that's the content of the broken /user: > > (sid)root@frodo:/user# tree > . > ├── extensions > │ ├── shared > │ │ ├── extensions.db > │ │ ├── lastsynchronized > │ │ ├── log.txt > │ │ └── registry > │ │ ├── > com.sun.star.comp.deployment.bundle.PackageRegistryBackend │ │ > ├── > com.sun.star.comp.deployment.component.PackageRegistryBackend │ > │ ├── > com.sun.star.comp.deployment.configuration.PackageRegistryBackend > │ │ │ ├── backenddb.xml > │ │ │ └── registered_packages.db > │ │ ├── > com.sun.star.comp.deployment.executable.PackageRegistryBackend │ > │ ├── > com.sun.star.comp.deployment.help.PackageRegistryBackend │ │ > │ └── backenddb.xml > │ │ ├── > com.sun.star.comp.deployment.script.PackageRegistryBackend │ │ > └── com.sun.star.comp.deployment.sfwk.PackageRegistryBackend │ > └── tmp > │ ├── extensions > │ ├── extensions.db > │ └── registry > │ ├── > com.sun.star.comp.deployment.bundle.PackageRegistryBackend │ > ├── > com.sun.star.comp.deployment.component.PackageRegistryBackend │ > ├── > com.sun.star.comp.deployment.configuration.PackageRegistryBackend > │ │ ├── backenddb.xml > │ │ └── registered_packages.db > │ ├── > com.sun.star.comp.deployment.executable.PackageRegistryBackend │ > ├── > com.sun.star.comp.deployment.help.PackageRegistryBackend │ > │ └── backenddb.xml > │ ├── > com.sun.star.comp.deployment.script.PackageRegistryBackend │ > └── com.sun.star.comp.deployment.sfwk.PackageRegistryBackend > └── uno_packages > └── cache > ├── log.txt > ├── registry > │ ├── > com.sun.star.comp.deployment.bundle.PackageRegistryBackend │ ├── > com.sun.star.comp.deployment.component.PackageRegistryBackend │ > ├── > com.sun.star.comp.deployment.configuration.PackageRegistryBackend > │ │ ├── backenddb.xml > │ │ └── registered_packages.db > │ ├── > com.sun.star.comp.deployment.executable.PackageRegistryBackend │ > ├── com.sun.star.comp.deployment.help.PackageRegistryBackend │ │ > └── backenddb.xml > │ ├── > com.sun.star.comp.deployment.script.PackageRegistryBackend │ └── > com.sun.star.comp.deployment.sfwk.PackageRegistryBackend ├── > uno_packages > └── uno_packages.db > > 31 directories, 15 files > If you know that this is the complete list, including 15 lines of "rm -f" and 31 lines of "rmdir ... 2> /dev/null || true" in depth-first order would seem best to me. Or do find /user -name 'com.sun.star*PackageRegistryBackend' -print0 | xargs -0 --no-run-if-empty rm -rf and then delete the rest by hand. But this is already more fragile. > > Or look if something exists there and warn the user that he > > should clean up by hand. > > That could be done, yes... If you can't limit the list of files, that's the only reasonable solution, IMHO. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org