Path: ...!weretis.net!feeder8.news.weretis.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rbowman <bowman@montana.com>
Newsgroups: comp.os.linux.misc
Subject: Re: Case Insensitive File Systems -- Torvalds Hates Them
Date: 3 May 2025 03:10:58 GMT
Lines: 34
Message-ID: <m7lfq1Fsk04U1@mid.individual.net>
References: <pan$4068a$3910f4f1$8cbecede$9e42905e@linux.rocks>
	<20250428080014.0000347f@gmail.com> <m79tdsF2bf6U1@mid.individual.net>
	<20250428111242.00007426@gmail.com>
	<pan$c046d$e87ef491$a3427b7a$ac576dbc@linux.rocks>
	<slrn1011nu8.46v.rotflol2@geidiprime.bvh> <vurjl9$2pskn$1@dont-email.me>
	<slrn1013t50.1aev.rotflol2@geidiprime.bvh>
	<vAGdnR-Fj9qGS4_1nZ2dnZfqn_udnZ2d@giganews.com>
	<slrn1016uic.2qk.rotflol2@geidiprime.bvh> <m7hgt7F8mvgU5@mid.individual.net>
	<6813f997@news.ausics.net> <vv100f$3nhss$1@dont-email.me>
	<W8UQP.63778$vo1.35298@fx15.iad> <vv14d9$3rgrd$1@dont-email.me>
	<Fd_QP.4$B6%8.3@fx33.iad> <vv1ued$lrj7$2@dont-email.me>
	<kHbRP.19683$U3L2.16365@fx16.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net m4wZtTUFEa81vtpCkPyjjgG3c/GqOuAdpJgAglCYuQPeFoFVXA
Cancel-Lock: sha1:+dZS0cIwQuOzFsNCsBl6nG6i+TQ= sha256:z0tnQqD0UTG5hv1TGvwhKOG5A7+q9/otUMW3BzSA7P8=
User-Agent: Pan/0.160 (Toresk; )
Bytes: 3193

On Fri, 02 May 2025 22:29:36 GMT, Charlie Gibbs wrote:

> It probably wasn't "work", I forget now.  All I remember is that it was
> done in such a way as to make clean-up very ugly. Hopefully Micro Focus
> cleaned up their act not long afterwards.

In our system when an incident was completed it was archived in a DB2 
database. If for some reason the server on the DB2 machine couldn't be 
reached it was stored locally as a file that would be uploaded later.

The site was usually configured with a backup machine running in parallel, 
often on a physically remote site in case the dispatch center was flooded 
(it happened a couple of times). It usually worked well but one evening 
the switchover didn't go well. Somehow, it's always after 5 PM when things 
go to hell.

The problem with a backup site is it is out of sight and out of mind. The 
DB2 server had changed but the configuration on the remote site hadn't. It 
was doing what it was supposed to do, store a file if it couldn't send it 
to DB2. For months...

The logic was the main controller would check to see if any store files 
needed to be uploaded during its idle time, basically doing a scandir() to 
find the oldest. That pretty much stopped the controller in its tracks. 
When we logged into the site and tried to see what was in the directory 
with Explorer, that locked up the whole machine. After getting control 
back we very gingerly deleted the directory without even trying to see 
what was inside. 

It may have been the NutCracker implementation on Windows, but using the 
native Windows API  FindFirstFile/FindNextFile was a lot faster than 
scandir.  You need to be careful with using Cygwin or Nutcracker when 
implementing POSIX functions on Windows. Mostly they work fine but there 
are pitfalls.