[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

dpkg and lchown


It's almost unbelieveable, but Darwin does not have the lchown() function. dpkg detects this and uses chown() instead. That's problematic for two reasons:

1) It changes the owner of the symlink's destination, which is not what we want.

2) If the destination of the symlink doesn't exist, chown() will fail, causing dpkg to abort the operation. This can happen when a package contains symlinks that point at other symlinks - the sorting done by dpkg-deb when creating packages doesn't help in this case. I encountered this problem with gtk+.

The patch below (taken against the v1_9 branch) fixes that. When lchown() is not supported, it doesn't try to set the owner of symlinks at all.


Index: main/archives.c
RCS file: /cvs/dpkg/dpkg/main/archives.c,v
retrieving revision
diff -u -r1.28.4.3 archives.c
--- main/archives.c	2001/05/28 21:32:23
+++ main/archives.c	2001/07/26 14:42:53
@@ -547,12 +547,10 @@
     debug(dbg_eachfiledetail,"tarobject SymbolicLink creating");
     if (lchown(fnamenewvb.buf,
-    if (chown(fnamenewvb.buf,
nifd->namenode->statoverride ? nifd->namenode->statoverride->uid : ti->UserID, nifd->namenode->statoverride ? nifd->namenode->statoverride->gid : ti->GroupID))
       ohshite(_("error setting ownership of symlink `%.255s'"),ti->Name);
   case Directory:
     /* We've already checked for an existing directory. */
@@ -608,10 +606,8 @@
         ohshite(_("unable to make backup symlink for `%.255s'"),ti->Name);
       if (lchown(fnametmpvb.buf,stab.st_uid,stab.st_gid))
-      if (chown(fnametmpvb.buf,stab.st_uid,stab.st_gid))
         ohshite(_("unable to chown backup symlink for `%.255s'"),ti->Name);
     } else {
       debug(dbg_eachfiledetail,"tarobject nondirectory, `link' backup");
       if (link(fnamevb.buf,fnametmpvb.buf))

chrisp a.k.a. Christoph Pfisterer   "Any sufficiently advanced
cp@chrisp.de - http://chrisp.de      bug is indistinguishable
PGP key & geek code available        from a feature."

Reply to: