The following patch unlinks (deletes) files, symlinks, FIFOs, devices
etc before writing them when extracting CPIOs. It doesn't delete
directories. This stops weird behaviour like:
1) writing through symlinks created in earlier CPIOs. eg foo->bar in
the first CPIO. Having foo as a non link in a subsequent CPIO,
results in bar being written and foo remaining as a symlink.
2) if the first version of file foo is larger than foo in a
subsequent CPIO, we end up with a mix of the two. ie. neither
the first or second version of /foo.
3) special files like devices, fifo etc can't be overwritten in
subsequent CPIOS.
With this patch, the kernel will more closely replicate
for i in *.cpio; do cpio --extract --unconditional < $i ; done
This patch doesn't break hardlinks like my previous attempt.
Signed-off-by: Michael Neuling <[email protected]>
---
initramfs.c | 3 +++
1 files changed, 3 insertions(+)
Index: linux-2.6.15/init/initramfs.c
===================================================================
--- linux-2.6.15.orig/init/initramfs.c
+++ linux-2.6.15/init/initramfs.c
@@ -249,6 +249,7 @@ static int __init do_name(void)
if (dry_run)
return 0;
if (S_ISREG(mode)) {
+ sys_unlink(collected);
if (maybe_link() >= 0) {
wfd = sys_open(collected, O_WRONLY|O_CREAT, mode);
if (wfd >= 0) {
@@ -263,6 +264,7 @@ static int __init do_name(void)
sys_chmod(collected, mode);
} else if (S_ISBLK(mode) || S_ISCHR(mode) ||
S_ISFIFO(mode) || S_ISSOCK(mode)) {
+ sys_unlink(collected);
if (maybe_link() == 0) {
sys_mknod(collected, mode, rdev);
sys_chown(collected, uid, gid);
@@ -291,6 +293,7 @@ static int __init do_copy(void)
static int __init do_symlink(void)
{
collected[N_ALIGN(name_len) + body_len] = '\0';
+ sys_unlink(collected);
sys_symlink(collected + N_ALIGN(name_len), collected);
sys_lchown(collected, uid, gid);
state = SkipIt;
Le mercredi 22 février 2006 à 10:45 +1100, Michael Neuling a écrit :
> The following patch unlinks (deletes) files, symlinks, FIFOs, devices
> etc before writing them when extracting CPIOs. It doesn't delete
> directories. This stops weird behaviour like:
> 1) writing through symlinks created in earlier CPIOs. eg foo->bar in
> the first CPIO. Having foo as a non link in a subsequent CPIO,
> results in bar being written and foo remaining as a symlink.
I've tended to think of this as a feature, actually. In Ubuntu, for
instance, we might have 2.6.15-8 and 2.6.15-9 which represent different
ABIs from security updates or other changes. If I have a module that is
intended to be compatible with both, I might setup /lib/modules/generic
to be a symlink to /lib/modules/2.6.15-9/ and unpack the modules after
the symlink is expected to be there.
(I don't think we use this feature right now, but I had tested it and
noted it before. It's very convenient, since it's the exact same
behaviour that dpkg itself has)
Tks,
Jeff Bailey
* Canonical Ltd * Ubuntu Service and Support * +1 514 691 7221 *
Linux for Human Beings.
Jeff Bailey wrote:
>
> I've tended to think of this as a feature, actually. In Ubuntu, for
> instance, we might have 2.6.15-8 and 2.6.15-9 which represent different
> ABIs from security updates or other changes. If I have a module that is
> intended to be compatible with both, I might setup /lib/modules/generic
> to be a symlink to /lib/modules/2.6.15-9/ and unpack the modules after
> the symlink is expected to be there.
>
This is pretty broken for a bunch of other reasons, though. In
particular, it prevents the very useful behaviour of providing a symlink
in entry A that can be overridden by a file in entry B.
> (I don't think we use this feature right now, but I had tested it and
> noted it before. It's very convenient, since it's the exact same
> behaviour that dpkg itself has)
I would personally consider that a bug in dpkg :-/
-hpa