Re: [Pan-users] pan on windows

[Duncan]

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