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
