On 4/12/20, to...@tuxteam.de <to...@tuxteam.de> wrote: > On Sun, Apr 12, 2020 at 08:43:12AM -0500, Richard Owlett wrote: >> Using Synaptic I: >> 1. searched package names for "info" >> 2. selected it >> 3. clicked Apply >> 4. received error message saying >> >E: Could not open lock file /var/cache/apt/archives/lock - open (2: No >> > such file or directory) >> >E: Could not open file descriptor -1 >> >E: Unable to lock the download directory > > Question: is there a /var/cache/apt/archives directory? There should > be one.
DISCLAIMER: I see Reco's very succinct answer. Kudos! I decided to still send mine out. Maybe it will help a newbie somewhere get to know their own system better somehow. I can still remember the first time of TRUSTING command line package management. Major YEEHAW! moment in my Linux usage overall. I've never looked back. :) So my observation to this thread is........ Maybe this is a Synaptic thing that it doesn't work when that lock's missing AND that it doesn't recreate that lock file on the fly? As tomas asked, what about... looking first to see if there actually is that file in place to see if it's falsely being reported as missing? (Sounds like that's a done deal.) Then, if it really *is* missing: What *I* would try since I've been in this spot in various similarly different scenarios is run something like "apt(-get) upgrade". That command might easily put that file back in place. It did for me just now. That command then stops and waits for user interaction. The action can be cancel(l)ed without any further system changes occurring. The reason I know to try that is because that lock file and the ones at "/var/lib/dpkg/lock" and "/var/lib/dpkg/lock-frontend" will, on rare occasion, get locked up for whatever reasons. If I "delete" those by renaming so they're still available as backup then rerun an affected apt(-get) command, things go back to normal when dpkg and/or apt(-get) recreate those lock files on the fly. It's odd to me that Synaptic's not replacing a missing lock file, but it may be on purpose by Developer design. Or maybe Synaptic doesn't "know how" to do that... or doesn't have the right permissions reach deeper into the system or something... ? It occurred to me to check the dotDEB archive files for both dpkg and apt since I experience this with both of them. Nope, neither package contains those files as part of their base installation. Rightly or wrongly, that causes me to a-sume those lock files are generated on the fly, at least on the first run of a program after installation.. OR in instances such as my experiences where I have to force the situation via lock file deletion WHEN my setup... locks up for whatever reason. To test that theory, I just ran "apt-get update", and those three files maintained their previous creation time stamps that are at least an hour old... or two days old because I JUST encountered this with dpkg a couple days ago (TWICE). That implies to me that they're initially generated then stand their ground in that creation state until borked again at some future point in time. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * hops with birdseed *