chdir() back to old working directory is pointless and can fail

Binary package hint: apt

It seems that the behaviour of "apt-get update" in Lucid includes a chdir() to /var/lib/apt/lists/ to do something, and then a chdir() back to what getcwd() returned prior to the chdir().

This chdir()ing back to the original working directory is pointless. The process is going to exit, and the working directory will be that of the parent process.

It can also fail, causing the "apt-get update" to exit 100 needlessly, in a Kerberised NFS environment where root cannot access the working directory that apt-get was in when it was invoked under sudo.

e.g.

I'm in /home/apollock

I invoke "sudo apt-get update"

It does its chdir()ing to /var/lib/apt/lists
It tries to chdir() back to /home/apollock
It gets an EACCES from this chdir() and decides to throw its hands up and return 100.

Here's a snippet from running it under strace:

open("/var/lib/apt/lists/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
getcwd("/home/apollock/REDACTED", 298) = 59
chdir("/var/lib/apt/lists/") = 0
getdents(5, /* 94 entries */, 32768) = 8656
getdents(5, /* 0 entries */, 32768) = 0
close(5) = 0
chdir("/home/apollock/REDACTED") = -1 EACCES (Permission denied)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
brk(0x145a000) = 0x145a000
open("/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5
fcntl(5, F_SETFD, FD_CLOEXEC) = 0
fcntl(5, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
open("/var/lib/dpkg/updates/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
getdents(6, /* 2 entries */, 32768) = 48
getdents(6, /* 0 entries */, 32768) = 0
close(6) = 0
close(5) = 0
close(4) = 0
write(2, "E: ", 3) = 3
write(2, "Unable to change to /home/apollo"..., 111) = 111
write(2, "\n", 1) = 1
close(3) = 0
exit_group(100) = ?