Dominique Dumont posted on Wed, 23 Mar 2022 11:51:20 +0100 as excerpted: > On Wednesday, 23 March 2022 11:21:54 CET Tom Tanner via Pan-users wrote: >> I've been unable to save articles. The article is downloaded fine, but >> it produces a xxxxx.ERRORS file instead, >> with the contents >> >> ERROR: Write error on target file D:\Caches\TempDir\Temp\uuZNQJJ1: Bad >> file descriptor > > That's a known issue on Windows: > https://gitlab.gnome.org/GNOME/pan/-/issues/106
While I can't do MS due to the EULA, the fact that the error persists no matter where you save the file, as well as the pointer to %TEMP%, indicates it's a problem there. How much free space on that partition? Just in case, you've tried a full reboot (not just a hibernate), right? What are the results of a fsck/ checkdisk/whatever run on that partition? And assuming you have the space, does starting pan with $TEMP pointed at a different partition (maybe a USB stick if you don't have a spare partition available) change the result? .... OT from here on but some may find the below Subject=TEMP "rant-story" interesting (and others should but regrettably won't...): Back over two decades ago now, before MS jumped the eXPrivacy shark and I switched to Linux as a result, I used to run the MSIE public betas and was active in the associated MS newsgroups. That was when they were trying to integrate IE with the explorer shell, and one of the first betas where MSIE was running all the time as part of the shell had a very nasty $TEMP and IE cache related bug: If you ran defrag it would corrupt-by-cross-linking the IE cache along with other random files on the same partition, with those files being overwritten by IE cache data. A number of people running that beta lost some pretty critical files as a result of that bug. But on my system, despite a regularly scheduled defrag that I never altered the schedule for during the beta, I never lost anything significant, because I had a policy of putting both the IE cache and $TEMP on a dedicated TEMP partition. Nothing permanent or critical was ever stored there except very temporarily, as I downloaded it or whatever. Turns out the bug was that for performance reasons IE was caching the disk address of its cache index file(s) in memory and shortcutting the lookup every time it wanted to write something to the cache. Then defrag would come along and move the index files elsewhere and IE, not knowing anything about it, would blindly write to where they *HAD* been, overwriting whatever was now in those disk blocks in the process. As long as IE was an ordinary app that was just loaded temporarily while you browsed or downloaded files, very few people were affected (only those who happened to run defrag at the same time, which wouldn't be many because of the performance drag of all the disk access on other operations so most would defrag, if they knew enough to do it at all, only when the computer was otherwise idle), but as soon as it was integrated into the shell and thus running constantly, anyone running defrag was affected. MS solved the problem in the next beta (or release, which I think it actually was in that case as IIRC the bug was in the second public beta of two) by marking the IE cache index with the SYSTEM attribute, which worked because defrag wouldn't touch SYSTEM attribute files -- they were left where the were. But all the bug could overwrite on my system were temporary files in any case, because I had a dedicated TEMP partition with IE's cache pointed there too (because I reasoned that those files were cache only and thus temporary as well). So I didn't have to care what it overwrote, and literally did NOT care because even after the bug was known I didn't bother changing my defrag schedule or what was defragged, at all, as long as it stayed on the dedicated TEMP partition. While I obviously had the "TEMP goes on a dedicated partition" rule before that, that was one of the more concrete and lasting computer lessons/ experiences of my life, becoming an absolute THOU SHALT NOT MIX TEMP WITH ANYTHING YOU VALUE personal commandment since. I kept it when I moved to Linux, where the vars are normally $TMP and $TMPDIR, with various cache vars pointed into the same partition, these days generally a tmpfs (a RAM- only virtual filesystem), so files that go there never actually hit disk, these days an SSD, at all. Of course the other lesson from that is the sysadmin's primary rule of backups and data value, that being "You define the actual value of your data not by any arbitrary claims as to its value, but by the number and frequency of the backups you have of that data. It follows that if it's not backed up, the working copy is all you have, you are by definition calling that data of only trivial value, not worth the time and trouble to back it up at all and not worth worrying about if it gets corrupted/ deleted (I say as I have a fresh backup of my packages partition going in another window). That too has served me time and time again, particularly given the fact that I tend to run betas and even live-git versions of various packages, including earlier versions of my current filesystem, btrfs. (Unfortunate people would write to the then-still-listed-as-experimental- btrfs mailing list telling tales of how they lost access to wedding photos, etc. Well I guess despite their claims to the contrary their actions, or in this case their LACK OF backup actions, while using a filesystem publicly known to not be production-ready to store those photos, spoke louder than their words, as they defined by those actions that those wedding photos were of only trivial value, not worth the hassle to backup and not worth worrying about if lost.) Of course the sysadmin's second rule of backups is that a backup cannot be defined as a backup until it has been tested to be actually restorable under conditions similar to those you'd be using if you actually had to restore it. (That is, it can be restored from your rescue disk, USB stick, etc, where you have access to any documentation necessary to figure out how to do so, etc, and you've tested that said rescue disk/stick/etc is actually bootable...) Until that restore test has been completed successfully, it's an intended backup in process, not a backup. /rant -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
