gconf2 try's to remove /etc completely when purging
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gconf2 (Debian) |
Fix Released
|
Undecided
|
Unassigned | ||
gconf2 (Ubuntu) |
Invalid
|
High
|
Sebastien Bacher |
Bug Description
Automatically imported from Debian bug report #270967 http://
In Debian Bug tracker #270967, Sebastien Bacher (seb128) wrote : Re: Bug#270967: gconf2 try's to remove /etc completely when purging | #1 |
Debian Bug Importer (debzilla) wrote : | #2 |
Automatically imported from Debian bug report #270967 http://
Debian Bug Importer (debzilla) wrote : | #3 |
Message-ID: <email address hidden>
Date: Fri, 10 Sep 2004 11:45:04 +0200
From: Klaus Ethgen <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: gconf2 try's to remove /etc completely when purging
-----BEGIN PGP SIGNED MESSAGE-----
Package: gconf2
Version: 2.6.3-2
Severity: critical
When removing (purging) gconf2 it trys to remove /etc c ompletely!
This will destroy the whole system if /etc can be removed on it and is not
protected as on my system.
- -- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (800, 'testing'), (70, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.27
Locale: LANG=de_DE, LC_CTYPE=de_DE (ignored: LC_ALL set to de_DE)
Versions of packages gconf2 depends on:
ii libatk1.0-0 1.6.1-3 The ATK accessibility toolkit
ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an
pn libgconf2-4 Not found.
ii libglib2.0-0 2.4.6-2 The GLib library of C routines
ii libgtk2.0-0 2.4.9-1 The GTK+ graphical user interface
ii liborbit2 1:2.10.2-1.1 libraries for ORBit2 - a CORBA ORB
ii libpango1.0-0 1.4.1-2 Layout and rendering of internatio
ii libpopt0 1.7-4 lib for parsing cmdline parameters
ii libxml2 2.6.11-3 GNOME XML library
ii zlib1g 1:1.2.1.1-5 compression library - runtime
- -- no debconf information
- --
Klaus Ethgen http://
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <email address hidden>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iQEVAwUBQUF3oJ+
SqMkHHiKU4xz6ht
OVqqmobp5HX0Z40
YBmOfABMI+
TQlJRl4/
+aDcexCxsBBE0/
=YrFu
-----END PGP SIGNATURE-----
In Debian Bug tracker #270967, Klaus Ethgen (klaus-ethgen) wrote : | #4 |
-----BEGIN PGP SIGNED MESSAGE-----
Hi,
Am Fr den 10. Sep 2004 um 12:47 schriebst Du:
> Could you provide some details ? Are you sure that the /etc dir has been
> deleted by gconf2 ?
When I purged the package first it failed because /etc/gconf/2 was not found on
my system and then after I created it it prints:
rmdir: `/etc': Permission denied
when purging. /etc is not removable in my environment thank goodnes.
I did not check if it whould remove /etc if it whould be removable.
> "rmdir -p --ignore-
> empty dirs, /etc was empty on your box ?
No, but see above.
Hmm.. I didn't look to the postrm afterwards. I only did a
echo "#!/bin/sh" > /var/lib/
to remove it completely. But it is strange that the rmdir above give this
message.
Regards
Klaus
- --
Klaus Ethgen http://
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <email address hidden>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iQEVAwUBQUGPTZ+
0PZG4m/
ivSL/z2hQW18pfl
zlooC15xNO+
PV3zUKMfSg1Aq00
tfGG/rCurWRV5TV
=VbXL
-----END PGP SIGNATURE-----
Sebastien Bacher (seb128) wrote : | #5 |
The only removal on purge in gconf is this one:
gconf2.postrm: rmdir -p --ignore-
This only remove empty dirs ... NOTABUG imho
In Debian Bug tracker #270967, Sebastien Bacher (seb128) wrote : | #6 |
Le vendredi 10 septembre 2004 à 13:26 +0200, Klaus Ethgen a écrit :
> When I purged the package first it failed because /etc/gconf/2 was not found on
> my system and then after I created it it prints:
> rmdir: `/etc': Permission denied
> when purging. /etc is not removable in my environment thank goodnes.
You've purged only this one ? Do you remember which version of the
package it was ?
I've just tried in a fresh pbuilder, no problem ...
> I did not check if it whould remove /etc if it whould be removable.
Can you still reproduce the problem ?
> to remove it completely. But it is strange that the rmdir above give this
> message.
Yes, I don't understand where is the problem, but that's not a gconf
problem ... if "rmdir -p --ignore-
to remove /etc you have a problem but that with coreutils, not gconf.
Cheers,
Sebastien Bacher
In Debian Bug tracker #270967, Klaus Ethgen (klaus-ethgen) wrote : | #7 |
-----BEGIN PGP SIGNED MESSAGE-----
Hi,
Am Fr den 10. Sep 2004 um 13:41 schriebst Du:
> You've purged only this one ? Do you remember which version of the
> package it was ?
No. But see below...
> Can you still reproduce the problem ?
Yes, I did on a other host (sid, newest version, all my hosts have "chattr +i /").
- ---
xxxx:~# dpkg --force-all --purge gconf2
dpkg: gconf2: dependency problems, but removing anyway as you request:
libgnome2-common depends on gconf2 (>= 2.6.0-1).
libgnomevfs2-
libgconf2-4 depends on gconf2 (>= 2.6.4-2).
(Reading database ... 94571 files and directories currently installed.)
Removing gconf2 ...
Purging configuration files for gconf2 ...
rmdir: `/etc': Permission denied
dpkg: error processing gconf2 (--purge):
subprocess post-removal script returned error exit status 1
Errors were encountered while processing:
gconf2
- ---
When there is somethink inside of /etc/gconf then no problem. But when there is
nothing more inside this bug happens.
When I then recreate /etc/gconfd/2 and make a "chattr -i /" the purge work well
without erasing something from /etc.
As the /etc gets not really deleted, i think the severity can be lowered to
'normal'.
Regards
Klaus
- --
Klaus Ethgen http://
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <email address hidden>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iQEVAwUBQUGWd5+
1JkKHgLmTGlBCa0
ZH9m6JV18VOe6uf
bSFsJ7SH9GkW7l5
JW4GCsqOJjk4Ju6
d73zS7mFwuE44/
=fpP/
-----END PGP SIGNATURE-----
Debian Bug Importer (debzilla) wrote : | #8 |
Message-Id: <1094813225.
Date: Fri, 10 Sep 2004 12:47:05 +0200
From: Sebastien Bacher <email address hidden>
To: Klaus Ethgen <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#270967: gconf2 try's to remove /etc completely when purging
severity 270967 important
tag 270967 + unreproducible moreinfo
thanks
Le vendredi 10 septembre 2004 =E0 11:45 +0200, Klaus Ethgen a =E9crit :
> When removing (purging) gconf2 it trys to remove /etc c ompletely!
>=20
> This will destroy the whole system if /etc can be removed on it and is no=
t
> protected as on my system.
Hi,=20
Could you provide some details ? Are you sure that the /etc dir has been
deleted by gconf2 ?
The postrm command used on purge is:
"rmdir -p --ignore-
empty dirs, /etc was empty on your box ?=20
I'm changing the severity to important for the moment, this problem is
not reproducible.
Thanks,
Sebastien Bacher
In Debian Bug tracker #270967, Sebastien Bacher (seb128) wrote : | #9 |
Le vendredi 10 septembre 2004 à 13:56 +0200, Klaus Ethgen a écrit :
> Yes, I did on a other host (sid, newest version, all my hosts have "chattr +i /").
Ok, I've the problem too.
$ chattr +i /
$ dpkg --purge libgconf2-4 gconf2
and I get the same error
The weird point is that running "sh /var/lib/
purge" doesn't display any error, but the same line called by apt raises
an error ...
Anybody with an idea on this ?
BTW not a gconf problem ...
Thanks,
Sebastien Bacher
Debian Bug Importer (debzilla) wrote : | #10 |
Message-ID: <20040910112312
Date: Fri, 10 Sep 2004 13:26:05 +0200
From: Klaus Ethgen <email address hidden>
To: Sebastien Bacher <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#270967: gconf2 try's to remove /etc completely when purging
-----BEGIN PGP SIGNED MESSAGE-----
Hi,
Am Fr den 10. Sep 2004 um 12:47 schriebst Du:
> Could you provide some details ? Are you sure that the /etc dir has been
> deleted by gconf2 ?
When I purged the package first it failed because /etc/gconf/2 was not found on
my system and then after I created it it prints:
rmdir: `/etc': Permission denied
when purging. /etc is not removable in my environment thank goodnes.
I did not check if it whould remove /etc if it whould be removable.
> "rmdir -p --ignore-
> empty dirs, /etc was empty on your box ?
No, but see above.
Hmm.. I didn't look to the postrm afterwards. I only did a
echo "#!/bin/sh" > /var/lib/
to remove it completely. But it is strange that the rmdir above give this
message.
Regards
Klaus
- --
Klaus Ethgen http://
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <email address hidden>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iQEVAwUBQUGPTZ+
0PZG4m/
ivSL/z2hQW18pfl
zlooC15xNO+
PV3zUKMfSg1Aq00
tfGG/rCurWRV5TV
=VbXL
-----END PGP SIGNATURE-----
Debian Bug Importer (debzilla) wrote : | #11 |
Message-Id: <1094816506.
Date: Fri, 10 Sep 2004 13:41:46 +0200
From: Sebastien Bacher <email address hidden>
To: Klaus Ethgen <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#270967: gconf2 try's to remove /etc completely when purging
Le vendredi 10 septembre 2004 =E0 13:26 +0200, Klaus Ethgen a =E9crit :
> When I purged the package first it failed because /etc/gconf/2 was not fo=
und on
> my system and then after I created it it prints:
> rmdir: `/etc': Permission denied
> when purging. /etc is not removable in my environment thank goodnes.
You've purged only this one ? Do you remember which version of the
package it was ?
I've just tried in a fresh pbuilder, no problem ...
> I did not check if it whould remove /etc if it whould be removable.
Can you still reproduce the problem ?
> to remove it completely. But it is strange that the rmdir above give this
> message.
Yes, I don't understand where is the problem, but that's not a gconf
problem ... if "rmdir -p --ignore-
to remove /etc you have a problem but that with coreutils, not gconf.
Cheers,
Sebastien Bacher
Debian Bug Importer (debzilla) wrote : | #12 |
Message-ID: <20040910115639
Date: Fri, 10 Sep 2004 13:56:39 +0200
From: Klaus Ethgen <email address hidden>
To: Sebastien Bacher <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#270967: gconf2 try's to remove /etc completely when purging
-----BEGIN PGP SIGNED MESSAGE-----
Hi,
Am Fr den 10. Sep 2004 um 13:41 schriebst Du:
> You've purged only this one ? Do you remember which version of the
> package it was ?
No. But see below...
> Can you still reproduce the problem ?
Yes, I did on a other host (sid, newest version, all my hosts have "chattr +i /").
- ---
xxxx:~# dpkg --force-all --purge gconf2
dpkg: gconf2: dependency problems, but removing anyway as you request:
libgnome2-common depends on gconf2 (>= 2.6.0-1).
libgnomevfs2-
libgconf2-4 depends on gconf2 (>= 2.6.4-2).
(Reading database ... 94571 files and directories currently installed.)
Removing gconf2 ...
Purging configuration files for gconf2 ...
rmdir: `/etc': Permission denied
dpkg: error processing gconf2 (--purge):
subprocess post-removal script returned error exit status 1
Errors were encountered while processing:
gconf2
- ---
When there is somethink inside of /etc/gconf then no problem. But when there is
nothing more inside this bug happens.
When I then recreate /etc/gconfd/2 and make a "chattr -i /" the purge work well
without erasing something from /etc.
As the /etc gets not really deleted, i think the severity can be lowered to
'normal'.
Regards
Klaus
- --
Klaus Ethgen http://
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <email address hidden>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iQEVAwUBQUGWd5+
1JkKHgLmTGlBCa0
ZH9m6JV18VOe6uf
bSFsJ7SH9GkW7l5
JW4GCsqOJjk4Ju6
d73zS7mFwuE44/
=fpP/
-----END PGP SIGNATURE-----
Debian Bug Importer (debzilla) wrote : | #13 |
Message-Id: <1094821212.
Date: Fri, 10 Sep 2004 15:00:12 +0200
From: Sebastien Bacher <email address hidden>
To: Klaus Ethgen <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#270967: gconf2 try's to remove /etc completely when purging
Le vendredi 10 septembre 2004 =E0 13:56 +0200, Klaus Ethgen a =E9crit :
> Yes, I did on a other host (sid, newest version, all my hosts have "chatt=
r +i /").
Ok, I've the problem too.
$ chattr +i /=20
$ dpkg --purge libgconf2-4 gconf2
and I get the same error
The weird point is that running "sh /var/lib/
purge" doesn't display any error, but the same line called by apt raises
an error ...
Anybody with an idea on this ?
BTW not a gconf problem ...
Thanks,
Sebastien Bacher
In Debian Bug tracker #270967, Adrian Bunk (bunk) wrote : Why purging gconf2-common might erase your /etc | #14 |
severity 270967 critical
thanks
Hi Sebastien,
I think I can answer the following question you raised:
<-- snip -->
The weird point is that running "sh /var/lib/
purge" doesn't display any error, but the same line called by apt raises
an error ...
<-- snip -->
The problem is only triggered when /etc/gconf2/ is empty.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
In Debian Bug tracker #270967, Josselin Mouette (joss) wrote : Re: Bug#270967: Why purging gconf2-common might erase your /etc | #15 |
severity 270967 normal
clone 270967 -1
retitle 270967 gconf2-common fails to purge when /etc isn't removable
reassign -1 coreutils
retitle -1 rmdir should check emptiness before permissions
thanks
Le lundi 30 janvier 2006 à 03:23 +0100, Adrian Bunk a écrit :
> severity 270967 critical
> thanks
This is by no means a critical bug. There's no way this script can wipe
out your /etc.
> Hi Sebastien,
>
> I think I can answer the following question you raised:
>
> <-- snip -->
>
> The weird point is that running "sh /var/lib/
> purge" doesn't display any error, but the same line called by apt raises
> an error ...
>
> <-- snip -->
>
> The problem is only triggered when /etc/gconf2/ is empty.
This error message is triggered by rmdir trying to remove /etc.
Normally, rmdir -p --ignore-
remove /etc/gconf/2, then /etc/gconf, then /etc, and will stop with /etc
because it isn't empty.
On your system, the chattr -i prevents the removal of /etc, and rmdir
fails on "permission denied" instead of "directory not empty".
I'd say that, so that rmdir -p --ignore-
such systems, it should be made to check first if the directory is
empty, and then if it has the permissions to remove it. I'm creating a
clone report on coreutils, but maybe it is caused directly by the kernel
or libc - in which case it should still be possible to work around the
issue in coreutils.
Currently, rmdir --ignore-
* call rmdir(2)
* check errno
* ignore ENOTEMPTY
Maybe it could be modified to do the following:
* check if the directory is empty
* call rmdir(2)
I don't know whether this would be acceptable. Depending on the
coreutils maintainers' advice and decision, I will modify - or not - the
gconf2 scripts.
Regards,
--
.''`. Josselin Mouette /\./\
: :' : <email address hidden>
`. `' <email address hidden>
`- Debian GNU/Linux -- The power of freedom
In Debian Bug tracker #270967, Bob Proulx (bob-proulx) wrote : | #16 |
Josselin Mouette wrote:
> This error message is triggered by rmdir trying to remove /etc.
> Normally, rmdir -p --ignore-
> remove /etc/gconf/2, then /etc/gconf, then /etc, and will stop with /etc
> because it isn't empty.
I see in the gconf2-
run:
rm -f /etc/gconf/2/path
rmdir -p --ignore-
Can that instead be changed to the following so as to avoid trying to
remove /etc at all?
rm -f /etc/gconf/2/path
rmdir --ignore-
It just seems simpler this way.
Meanwhile, I have removed the moreinfo and unreproducible tags and am
forwarding this upstream.
Bob
In Debian Bug tracker #270967, Bob Proulx (bob-proulx) wrote : | #17 |
> Meanwhile, I have removed the moreinfo and unreproducible tags and am
> forwarding this upstream.
Actually I am doing that to the cloned bug 350541.
Bob
In Debian Bug tracker #270967, Bob Proulx (bob-proulx) wrote : rmdir --ignore-fail-on-non-empty fails with permission denied | #18 |
Please maintain the CC to both the bug number and the mailing list
when responding. Thanks.
Reported to the Debian BTS:
'rmdir --ignore-
unless it has insufficient permission to remove them, in which case it
fails. Can rmdir avoid failing in this case?
Here is a way to reproduce the issue. Root access is required in
order to have permission to set the immutable attribute. The
filesystem needs to be ext2-like in order to support it.
# mkdir testdir
# mkdir testdir/foo
# mkdir testdir/foo/bar
# mkdir testdir/foo/boo
# chattr +i testdir
# rmdir -p --ignore-
rmdir: testdir/foo: Permission denied
1
But without the immutable attribute:
# chattr -i testdir
# mkdir testdir/foo/bar
# rmdir -p --ignore-
0
This was found in a package postrm script which tried to clean up by
doing the following:
rm -f /etc/gconf/2/path
rmdir -p --ignore-
rmdir: `/etc': Permission denied
Bob
----- Forwarded *TRIMMED* message from Josselin Mouette <email address hidden> -----
From: Josselin Mouette <email address hidden>
Subject: Bug#270967: Why purging gconf2-common might erase your /etc
Date: Mon, 30 Jan 2006 10:10:57 +0100
[...TRIMMED CONTENT, ORIGINAL IN ARCHIVE...]
This error message is triggered by rmdir trying to remove /etc.
Normally, rmdir -p --ignore-
remove /etc/gconf/2, then /etc/gconf, then /etc, and will stop with /etc
because it isn't empty.
On your system, the chattr -i prevents the removal of /etc, and rmdir
fails on "permission denied" instead of "directory not empty".
I'd say that, so that rmdir -p --ignore-
such systems, it should be made to check first if the directory is
empty, and then if it has the permissions to remove it. I'm creating a
clone report on coreutils, but maybe it is caused directly by the kernel
or libc - in which case it should still be possible to work around the
issue in coreutils.
Currently, rmdir --ignore-
* call rmdir(2)
* check errno
* ignore ENOTEMPTY
Maybe it could be modified to do the following:
* check if the directory is empty
* call rmdir(2)
I don't know whether this would be acceptable. Depending on the
coreutils maintainers' advice and decision, I will modify - or not - the
gconf2 scripts.
Regards,
--
.''`. Josselin Mouette /\./\
: :' : <email address hidden>
`. `' <email address hidden>
`- Debian GNU/Linux -- The power of freedom
----- End forwarded message -----
In Debian Bug tracker #270967, Bob Proulx (bob-proulx) wrote : | #19 |
Bob Proulx wrote:
> Please maintain the CC to both the bug number and the mailing list
> when responding. Thanks.
Which would have been great if I had not been confused by the cloning
of this bug into two different bugs. My bad. Please keep
<email address hidden> instead of <email address hidden> in the CC
list. Sorry about that.
> Reported to the Debian BTS:
>
> http://
Bob
In Debian Bug tracker #270967, Jim Meyering (meyering) wrote : | #20 |
<email address hidden> (Bob Proulx) wrote:
> Please maintain the CC to both the bug number and the mailing list
> when responding. Thanks.
>
> Reported to the Debian BTS:
>
> http://
>
> 'rmdir --ignore-
> unless it has insufficient permission to remove them, in which case it
> fails. Can rmdir avoid failing in this case?
>
> Here is a way to reproduce the issue. Root access is required in
> order to have permission to set the immutable attribute. The
> filesystem needs to be ext2-like in order to support it.
>
> # mkdir testdir
> # mkdir testdir/foo
> # mkdir testdir/foo/bar
> # mkdir testdir/foo/boo
> # chattr +i testdir
> # rmdir -p --ignore-
> rmdir: testdir/foo: Permission denied
> 1
I've fixed it like this:
(but no test case yet -- volunteers welcome!)
Improve "rmdir --ignore-
* src/rmdir.c (remove_parents, main): With --ignore-
suppress a diagnostic also for e.g., EACCES, which can happen
with read-only media or when the parent directory has the immutable
attribute (set via chattr +i).
(errno_
* src/remove.c (is_empty_dir): Move function to ...
* src/system.h (is_empty_dir): ...here, and make it inline.
Suggested by Josselin Mouette in <http://
via Bob Proulx.
* NEWS: Mention the improvement.
Signed-off-by: Jim Meyering <email address hidden>
---
ChangeLog | 14 ++++++++++++++
NEWS | 10 +++++++++-
THANKS | 1 +
src/remove.c | 32 +------
src/rmdir.c | 36 +++++++
src/system.h | 30 +++++++
6 files changed, 86 insertions(+), 37 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 5e15325..017c307 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2008-01-30 Jim Meyering <email address hidden>
+
+ Improve "rmdir --ignore-
+ * src/rmdir.c (remove_parents, main): With --ignore-
+ suppress a diagnostic also for e.g., EACCES, which can happen
+ with read-only media or when the parent directory has the immutable
+ attribute (set via chattr +i).
+ (errno_
+ * src/remove.c (is_empty_dir): Move function to ...
+ * src/system.h (is_empty_dir): ...here, and make it inline.
+ Suggested by Josselin Mouette in <http://
+ via Bob Proulx.
+ * NEWS: Mention the improvement.
+
2008-01-29 Paul Eggert <email address hidden>
Don't modify argv in dd.
diff --git a/NEWS b/NEWS
index f474141..0d2d97d 100644
--- a/NEWS
+++ b/NEWS
@@ -1,12 +1,20 @@
GNU coreutils NEWS -*- outline -*-
-* Noteworthy changes in release 6.10 (2008-01-22) [stable]
+* Noteworthy changes in release 6.?? (2008-??-??) [stable]
** Bug fixes
ls no longer segfaults on files in /proc when linked with an older version
of libselinux. E.g., ls -l /proc/sys would dereference a NULL pointer.
+ "rmdir --ignore-
+ in more cases wh...
dino99 (9d9) wrote : | #21 |
Was fixed on 1.5.4 release
Changed in gconf2 (Debian): | |
importance: | Unknown → Undecided |
status: | Incomplete → New |
status: | New → Fix Released |
severity 270967 important
tag 270967 + unreproducible moreinfo
thanks
Le vendredi 10 septembre 2004 à 11:45 +0200, Klaus Ethgen a écrit :
> When removing (purging) gconf2 it trys to remove /etc c ompletely!
>
> This will destroy the whole system if /etc can be removed on it and is not
> protected as on my system.
Hi,
Could you provide some details ? Are you sure that the /etc dir has been
deleted by gconf2 ?
The postrm command used on purge is: fail-on- non-empty /etc/gconf/2" ... this only removes
"rmdir -p --ignore-
empty dirs, /etc was empty on your box ?
I'm changing the severity to important for the moment, this problem is
not reproducible.
Thanks,
Sebastien Bacher