Questa è una vecchia versione del documento!

Procedure di Test piattaforma eXtraWay - Documentazione Riservata

Introduzione

Scopo del presente documento è indicare, per ciascun modulo della Piattaforma eXtraWay di 3D Informatica, quale sia la procedura di test da eseguire per considerare valido lo sviluppo di una nuova funzionalità ovvero la correzione di una funzionalità esistente.
Oltre al suddetto compito il presente documento si prefigge anche di dare una capillare descrizione dell'avanzamento dei moduli della piattaforma eXtraWay, puntando l'attenzione sul primo di essi ovvero su eXtraWay Server, così da consentire a chiunque di capire esattamente da che data e quale versione è disponibile una funzionalità o correzione e come si debba far uso delle nuove funzionalità.
Compito dei diversi sviluppatori sarà quello di registrare in queste pagina gli interventi fatti (o le correzioni apportate) indicandoli in ordine cronologico così che le attività di test possano essere limitate alle novità, per una sessione di test rapido ovvero a tutti i punti riportati.

Nel riportare, man mano, gli interventi effettuati si suggerisce di indicare quanto meno:

La data dell'intervento
Il modulo coinvolto (Mod)
La versione del modulo o del prodotto cui far riferimento (Ver)
L'attività da svolgere per compiere i test in proposito
Il risultato che si deve ottenere e che possa considerarsi necessario e sufficiente perché il test possa dirsi superato.
Ogni nota esplicativa che consenta al tester di costituire l'ambiente adatto al test e/o valutare il comportamento del modulo o prodotto testato.

Di seguito gli interventi ordinati per data.
In essi si identifica il modulo e la versione di esso dalla quale la funzionalità o la correzione è disponibile e tutte le informazioni per riprodurre le condizioni di test.
I valori ammessi per il tipo di intervento sono:

CE: Correzione Errore
NC: Nuovo Comportamento
NF: Nuova Funzionalità
AL: Intervento di nuova funzionalità o correzione che richiede allineamento tra moduli della piattaforma.
IN: Intervento di nuova funzionalità o correzione che causa incompatibilità col passato
CA: Registrazione dell'emissione di una candidate, versione non ufficiale ma distribuita ugualmente per compiere verifiche e valutare la validità degli interventi compiuti

Procedure di Test Piattaforma eXtraWay

Quando si parla di Piattaforma eXtraWay essa viene solitamente associata all'emissione di un supporto nella quale si stabilisce quale insieme di moduli si possa considerare stabile e quindi possa e debba essere distribuito alla clientela.
In pratica, però, internamente a 3D, le attività che afferiscono alla Piattaforma eXtraWay vanno viste, in buona sostanza, come riferite e riferibili ad una data versione del server attorno al quale ruotano poi gli altri moduli (salvo alcune eccezioni).
Per cercare di rendere leggibile e fruibile questo documento, esso viene suddiviso in base alle diverse versioni del server eXtraWay se pure le indicazioni inerenti ai test potranno riferirsi a qualsiasi modulo della Piattaforma eXtraWay. In sostanza, quindi, nel consultare questo documento la prima sezione sarà sempre riferita alla versione in corso di sviluppo, quindi una versione di fatto “Candidate”.

25.7.0 "Candidate"

Data	Mod	Ver		Sintomo o Segnalazione
29/10 2014	xw	25.7.2 25.6.0	CE	Ripetuti crash del server a seguito del comando MSG_ACCOUNT.
	A quanto pare l'assegnazione in una mappa `std::map<std::string, std::string>` di un valore assegnato ad una chiave stringa vuota causa dei difatti, per lo meno in alcuni casi. Modificata la modalità per mezzo della quale si inserisce la chiave (usando una insert invece dell'assegnazione al valore con le quadre) ed inibita la conversione del nome archivio nel caso del comando MSG_ACCOUNT in quanto del tutto inutile.
	Rif.	eGrupWare #002511
15/10 2014	xw	25.7.2	CE	In caso di errata configurazione del file `<nomearchivio>.conf.xml` un'applicazione riesce comunque a caricare l'archivio.
	Il problema si deve al fatto che l'apertura dell'archivio convalida lo stato della configurazione e lamenta il fatto che essa sia eventualmente errata in qualche punto. Se però in seguito si richiede la struttura (chiavi) dell'archivio la stessa condizione d'errore, pur evidenziata dal server, veniva in seguito ignorata lasciando pervenire al chiamante un risultato apparentemente congruente. Corretto.
	Rif.	eGrupWare #002216
18/09 2014	xw	25.7.2 25.6.2	CE	L'esportazione di record con allegati non funziona correttamente.
	L'errore si manifesta solo su archivi nei quali gli ID degli allegati non sono stati registrati nelle collocazioni standard, vale a dire negli elementi `xw:file` ovvero nelle processing instructions `?xw-file` bensì in elementi/attributi standard seppure configurati opportunamente nel nomefile`.conf.xml`. In tal caso la presenza degli ID degli allegati, normalmente gestita in modo corretto, veniva gestita ignorando tali allegati¹⁾. Applicata anche in questo frangente la stessa funzione di mining del documento che si utilizza in fase di indicizzazione e gestione degli allegati.
	Rif.	eGrupWare #002444
05/09 2014	xw	25.7.2 25.6.1	CE	Errore ricostruzione gerarchia in ACL.
	L'errore si manifesta in quanto in sede di ricostruzione della gerarchia si rileva la presenza di chiavi di relazione già esistenti a dispetto della precedente cancellazione che avrebbe dovuto rimuoverle tutte. Questo di fatto non avviene a causa di un difetto della ricerca greater in presenza di chiavi cancellate. Quando questo avviene e si rileva la chiave desiderata ma la si trova cancellata, il posizionamento alla chiave successiva avviene correttamente ma si rileva per la stessa che la radice non è comune, condizione che porta il processo a non andare oltre, ovvero a non considerare la chiave come chiave da rimuovere (non appartenendo allo stesso insieme di chiavi). A dire il vero questo si evince con l'osservazione dell'errore non seguendo l'iter del codice che di fatto non dovrebbe comportarsi in questo modo, ma l'archivio corrotto (non sappiamo come) che ci è stato fornito evidenzia questa condizione. Presumo quindi che siano state rimosse delle chiavi di relazione (per spostare un ramo di relazione da un punto ad un altro) prima di procedere con la cancellazione complessiva e che quando si è giunti a quel punto le relazioni risultavano assenti pur non essendolo. Ora il processo di determinazione della chiave greater effettua un controllo coerente sul contenuto della chiave rilevata, sottoponendolo ad un nuovo compare che ci dice se la radice è comune o meno, condizione che fa la differenza.
	Rif.	eGrupWare #002424
11/07 2014	xw	25.7.0 25.6.1	CE	Estrema lentezza in catalogo.
	Quando una delle cartelle da elaborare contiene centinaia di migliaia di ulteriori cartelle `.file` il processo di acquisizione sbagliava nel cercare comunque di scandirne il contenuto pur sapendo di doverle ignorare. Il risultato è che con un elevato numero di cartelle le prestazioni avevano un crollo verticale. Corretto il processo in modo che non compia la scansione se si sa che la cartella va ignorata.
	Rif.	eGrupWare #002373
17/06 2014	xw	25.7.0 25.6.1	CE	Esiste ancora una vulnerabilità nel caricamento di allegati con percorso assoluto ma inserti relativi.
	In presenza di percorso assoluto si compieva la leggerezza di non provvedere alla normalizzazione dei suoi eventuali correttori relativi (/./ e /../).
	Rif.	eGrupWare #002343
17/06 2014	xw	25.7.0 25.6.1	CE	L'ordinamento di una selezione già ordinata in modo probabilistica da errore.
	Il problema si manifesta quando si cerca di creare un nuovo file di selezione ordinato ma i numeri di documenti hanno anche il valore del Ranking espresso da 255 a 0.
	Rif.	eGrupWare #002329
11/06 2014	xw	25.7.0 25.6.1	CE	Il caricamento di un documento da una raccolta causa un errore. Il numero del documento non viene riconosciuto.
	Effetto collaterale dell'introduzione del Pool d'Archivi. Il numero del documento veniva decorato con l'ID dell'archivio di appartenenza pur in assenza di un vero Pool.
	Rif.	eGrupWare #002325

25.6.0

Data	Mod	Ver		Sintomo o Segnalazione
30/04 2014	xw	25.5.4	CE	La ricerca Fuzzy da risultati incomprensibili.
	Il problema si manifesta quando la ricerca Fuzzy viene combinata con altre estensioni come ad esempio la ricerca estesa per Genere e Numero. In questo caso la ricerca per Genere e Numero viene compiuta prima e produce dei risultati che potrebbero condurre, una volta estesi in modalità Fuzzy a termini che diviene difficile ricondurre ai termine originale. Per tale ragione è stato cambiato l'ordine di esecuzione delle estensioni che ora è il seguente: - Wild Cards; - Fuzzy; - Fonetica; - Genere e Numero; - Thesaurus.
	Rif.	eGrupWare #002270
27/03 2014	xw	25.5.4	CE	L'ordinamento per date espresse in modalità ISO non avviene in modo corretto, ovvero non rispetta.
	Il problema riguarda un ordinamento di data. Ho notato che in un diverso punto del codice che predispone l'ordinamento ci si chiede se la data sia ISO o meno e si agisce di conseguenza, cosa che non accadeva nel caso utilizzato. E' stato sufficiente portare quella stessa correzione anche in questo punto per avere l'esito desiderato.
	Rif.	eGrupWare #002202
??/03 2014	xw	25.5.4	CE	Il tentativo di identificare la posizione di un documento in una selezione causa un errore inatteso.
	Nel dicembre 2013 sono stati compiuti degli interventi congiunti tra il Web Service ed il server eXtraWay. Quando il primo cerca di identificare la posizione logica di un record entro una selezione non procede più al caricamento pedissequo, uno alla volta, dei record della selezione sino ad identificare il proprio, bensì chiede al server di identificare la posizione con una modalità nuova del comando esistente. Questo però ha comportato che ma modifica nel server causasse un errore anziché un esito nullo. In questo modo, se il record non appartiene alla selezione, si ha un valore di ritorno inatteso. Modificato l'intervento di cui alla versione 25.4.0 per far sì che si torni regolarmente un esito nullo e non un errore.
	Rif.	eGrupWare #002197

25.5.3 "Candidate"

Data	Mod	Ver		Sintomo o Segnalazione
19/03 2014	xw	25.5.3	CE	Non viene chiamato correttamente il trigger `afterIndex` per una specifica unità informativa in caso di cancellazione.
	In caso di cancellazione non veniva inviato il `pne`, quindi l'esecutore del Trigger non era in grado di valutare a quale P.I. associarlo. Ora, se assente, viene calcolato.
	Rif.	eGrupWare #002183
17/03 2014	xw	25.5.3	CE	Nel ripetere una selezione con l'intenzione di applicare ad essa lo stesso ordinamento di altra selezione, non si riesce ad applicare tale ordinamento se esso è semplicemente il `REVERSE`.
	Compiuto quest'intervento. Ora se l'ordinamento di una selezione prende le mosse da altra ordinata semplicemente in modalità `REVERSE` tale ordinamento viene applicato.
	Rif.	eGrupWare #002179
17/03 2014	xw	25.5.3	CE	La ricerca per somiglianza di termini non funziona se si abbassa il numero di caratteri ogni quali ammettere un errore.
	Il debug della segnalazione evidenzia invece che se non c'è prefisso (ovvero se sin dal primo carattere la chiave può cambiare) il processo di estensione non veniva svolto. Corretto il comportamento del server. Si ricorda comunque che estendere senza alcun prefisso è potenzialmente portatore di problemi di performance, hang di server e quindi potenziali denial of service.
	Rif.	eGrupWare #002187

25.5.2 "Candidate"

Data	Mod	Ver		Sintomo o Segnalazione
17/02 2014	xw	25.5.2	CE	Capita, con una certa frequenza, che il server eXtraWay non riesca ad essere correttamente avviato a causa di una serie di semafori spuri che rimangono attivi anche al quando tutte le istanze di server sono state rimosse.
	Si tratta di un semaforo legato ad un log di debug. Questo log viene avviato sempre e comunque in partenza per poi essere “spento” ad un certo punto della via utile del server Master, ed eventualmente riacceso, in un secondo momento, qualora si espliciti il parametro `-d` sulla riga di comando del server (atta a registrare informazioni di debug in un file di log a parte). Il suo spegnimento automatico (dopo l'avvio automatico) in attesa di un eventuale riavvio avveniva in modo non corretto.
	Rif.	eGrupWare #001714
14/02 2014	xw	25.5.2	CE	Se si compie un errore nella sintassi della regola di ordinamento della selezione l'errore che viene tornato non è parlante.
	Adottato specifico codice d'errore e prodotto log significativo..
	Rif.	eGrupWare #002117
13/02 2014	xw	25.5.2	CE	Le funzioni di caricamento di allegati e file temporanei sono troppo deboli e consentono di caricare qualsiasi file leggibile dal server.
	Limitato quanto detto. Per i file temporanei si impone che il nome di file risultante al termine dell'elaborazione sia interno alla cartella dei file condivisi ²⁾ ovvero dei temporanei . Per gli allegati invece si impone che il nome del file sia calcolato da un codice numerico secondo le politiche del server mentre per i percorsi relativi si impone che il file sia interno alla cartella dell'archivio. Sono altresì vietate, senza altre condizioni, tutte le richieste effettuate con percorsi completi.
	Rif.	eGrupWare #002069

25.5.1 "Candidate"

Emesso 11/02/2014 per Egaf

Data	Mod	Ver		Sintomo o Segnalazione
11/02 2014	xw	25.5.1	CE	L'ordinamento in una ricerca in cascata viene applicato a tutte le ricerche anziché solo all'ultima.
	Un recente intervento (21/01/2014) teso a forzare l'ordinamento se espresso nella frase di ricerca provocava l'ordinamento su tutte le selezioni, anche quelle intermedie. Rettificato l'intervento in modo che sì possa impostare il flag di ordinamento se mancante ma che lo stesso flag venga abbattuto, e quindi ignorato, nelle ricerche intermedie.
	Rif.	eGrupWare #002102
10/02 2014	xw	25.5.0	CE	Il server non riesce più ad accedere a selezioni conservate in cache.
	A quanto pare una selezione in cache viene rimossa (o qualcosa di simile) probabilmente dal server che cancella i temporanei ma nel farlo il file rimane, di fatto, in uso. In seguito, quando un server deve verificare la data del file per scegliere se usare ancora quella cache o meno, viene rilevata una data apparentemente valida, ma poi quando si provvede ad aprire il file ed utilizzarne il contenuto, esso risulta vuoto/inesistente. Cambiato l'approccio. Il file viene aperto materialmente e se non esiste deve dare errore e poi verrà calcolato ex.novo.
	Rif.	eGrupWare #002102
04/02 2014	xw	25.5.0	CE	Si presentano errori silenti in composizione di un record XML in Lua. Il risultato è vuoto ma non si rileva alcuna condizione di reale errore.
	Assegnando ad un elemento o un attributo un valore questo dev'essere espresso in modo adeguato, ovvero deve avere un encoding noto ed esso dev'essere indicato in sede d'assegnazione. Questo per lo meno se l'encoding del testo che si imposta è diverso da `UTF-8` che rappresenta il default. Se valorizziamo un elmento o un attributo con un valore dichiarato (esplicitamente o implicitamente) come `UTF-8` ma che in realtà è espresso in un encoding differente, il DOM viene creato comunque (anche se mi sarei aspettato un errore tout-court) ma al momento di “renderizzarlo” il risultato fallisce e si produce quindi un esito vuoto. Ora invece si compie una verifica supplementare in sede di assegnazione di un valore, verifica effettuata per tutelarsi proprio da questo caso. Se si riscontra che il contenuto che si sta per impostare non è in nell'encoding attesa `UTF-8` il server da un errore bloccante che non consente di portare a termine l'operazione e che è chiaramente rilevabile tanto in sede di sviluppo quanto dai log del server in produzione.
	Rif.	eGrupWare #002096
31/01 2014	xw	25.5.0	CE	Nel trattamento di DOM XML si incorre in Crash del server in sede di cancellazione di nodi.
	Questo avviene, o per lo meno può avvenire, quando i nodi che si vanno a cancellare sono nidificati tra loro. Se il nodo padre viene cancellato prima del nodo figlio, all'atto della rimozione del nodo figlio esso risulta invalido ed il processo va in errore. Implementata ed esposta alle DLL una modalità per cancellare i nodi in blocco (non uno alla volta). Ora i nodi vengono svincolati dal documenti e gli uni dagli altri e poi rimossi. In questo modo il problema dovrebbe svanire.
	Rif.	eGrupWare #T02992
31/01 2014	xw	25.5.0	CE	Nonostante sia ammessa la collisione di alcuni utenti essi continuano a confliggere se l'IP è diverso.
	Problema legato al `case` con cui viene espresso io nome utente che li considerava uguale all'atto della verifica iniziale (diciamo check del login) ma poi non conduceva ad un comportamento corretto quando di quell'utente si dovevano verificare le credenziali.
	Rif.	eGrupWare #002076
21/01 2014	xw	25.5.0	CE	L'espressione di ricerca che comprende la regola di ordinamento non viene presa in esame, l'esito della selezione non è ordinata.
	Corretto il trattamento della regola di ordinamento che non ritoccava flags necessari a procedere realmente con l'ordinamento.
	Rif.
21/01 2014	xw	25.5.0	NF	E' necessario fare dagli script Lua il caricamento diretto di un record sulla base di una chiave univoca.
	Esposti metodi che derivano dalla ricerca “Fast” che evita tutto il trattamento delle selezioni e va direttamente sulle chiavi.
	Rif.

25.4.0

Data	Mod	Ver		Sintomo o Segnalazione
23/12 2013	xw	25.3.0	CE	Il server rifiuta il salvataggio di un documento dichiarandolo non Well Formed.
	Il documento presenta in se una moltitudine di Processing Instructions segno evidente che per modificare il record è stato usato più volte un documento frutto di una selezione, potenzialmente con un lock ottimistico, e non un documento regolarmente caricato. Il server deve verificare se nel documento siano richiesti dei namespace e, se sì, che essi siano dichiarati o, in alternativa, aggiunge la dichiarazione mancante. Per farlo, non potendo fare il parsing del documento che potrebbe non essere appunto Well Formed si affida ad un algoritmo euristico. Quando questo incontra però una Processing Instruction che contiene esattamente il nome dell'elemento che dichiara il namespace, vale a dire `xmlns:xw`, il procedimento si convince di aver trovato la dichiarazione attesa e non l'aggiunge. La dichiarazione in verità manca ed il risultato è che il documento risulta non conformato correttamente. Modificato il processo “euristico” in modo che non si faccia ingannare e trovi la dichiarazione del namespace solo se espressa in modo completo e corretto.
	Rif.	eGroupWare #002021.
23/12 2013	xw	25.3.0	CE	La gerarchia di un archivio ACL risulta corrotta ed anche rifacendola non si ottiene risultato.
	Dai test effettuati si nota che ricostruendo integralmente l'archivio il problema svanisce. Ho ragione di pensare che sia un problema affine a quello di cui alla segnalazione #1980 e come tale si considera chiuso sino a contr'ordine.
	Rif.	eGroupWare #001981.
20/12 2013	xw	25.3.0	NF	Identificazione della posizione di un documento fisico entro una selezione.
	Per incontrare esigenze legate ai Web Services che hanno un modo discutibile di valutare quale sia il numero fisico e/o logico di un documento in selezione è stato necessario introdurre un comportamento del server che consente di tradurre un numero fisico di documento nella sua relativa posizione entro una selzione.
	Rif.	eGroupWare #002025.
03/12 2013	xw	25.3.0 22.3.1.8	CE	La navigazione del Thesaurus torna valori inattesi.
	Quando si naviga un Thesaurus si tende a compiere una serie di letture “greater” e se queste non danno l'esito atteso si procede, in alcuni casi, a letture “lower”. La lettura lower non faceva correttamente tutti i test del caso quindi si rischiava di ricadere in termini appartenenti alla chiave precedente senza rendersi conto che non c'era congruenza tra i termini. Replicato il test che si fa per verificare se la prima chiave letta sia corretta o meno anche su quella che si verifica al “secondo giro”.
	Rif.	eGroupWare #001962.
03/12 2013	xw	25.3.0	CE	La navigazione del Thesaurus non torna i dati previsti ed il Web Service di `xdocwaydoc` si rifiuta di salvare un record.
	In primo luogo il server fa quello che è previsto che faccia in quanto il Thesaurus non è composto in modo corretto. In esso alcune chiavi (andata e ritorno) differiscono per il case, rendendo inefficiacie il processo di navigazione che, giunto al nodo necessario, di fatto non sa scendere in esso ed estrarne i contenuti. Dal momento, però, che in un recenete passato si è deciso di abbandonare la modalità `case sensitive` del Thesaurus a favore di una più sensata modalità `case insensitive` e che sul trattametno delle chiavi del `B+Tree` gli interventi sono già stati fatti, il problema andava affrontato anche lato server. Ora i metodi che compiono la navigazione del Thesaurus sono stati modificati per essere `case insensitive`ed anche se il Thesaurus viene composto in modo non del tutto corretto ora il server è sufficientemente tollerante per non impedire la sua navigazione.
	Rif.	eGroupWare #001980.
22/10 2013	xw	25.3.0	CE	In caso di ricerca ordinata e sottoposta a Cache si ha un errore di apertura.
	Il difetto è dovuto al fatto che l'ordinamento non teneva conto della condizione di Cache on imposto sulla selezione e produceva sempre una selezione nuova, volatile, rimuovendo per altro quella Chaced. Questo comportava il fatto che la ricerca veniva replicata ogni volta ed il suo contenuti, seppure ordinato, andava comunque perso. Ora l'ordinamento salva la selezione ordinata sopra a quella Cached così da conservarla già nella più corretta delle forme.
	Rif.	eGroupWare #001872.
15/10 2013	xw	25.3.0	CE	E' necessario poter compiere delle post lavorazioni una vota che si è condotta a termine un'importazione via WatchDoc.
	Introdotto un nuovo Trigger da evocarsi al termine di ciascuna elaborazione effettuata tramite WatchDoc.
	Rif.	eGroupWare #001771.
14/10 2013	xw	25.3.0	CE	In presenza di un file `<nomearchivio>.dsp` malformato, privo della dichiarazione di alcune chiavi o addirittura assente, il server non presenta errori e consente l'introduzione nel Thesaurus d'archivi di chiavi malformate.
	Inibita l'apertura di un archivio se non è preente il file `.dsp` opportuno e se in esso non sono citate, per lo meno, tutte le chiavi che il file di configurazione d'archivio³⁾ richiede.
	Rif.	eGroupWare #001852.
14/10 2013	xw	25.3.0	CE	Il server in alcuni casi da errore di caricamento di un file `3dp..`.
	Non mi riesce di riprodurre l'errore. Impostato un nuovo controllo di chiusura del file per assicurarmi che finisca su disco.
	Rif.	eGroupWare #001848.
14/10 2013	xw	25.3.0	CE	Crash del server Master in importazione file PDF nell'applicazione Sestra.
	Sia il thread del server che la funzione principale della libxwwd.so usavano buffers non correttamente dimensionati (misura obsoleta). Portando il dimensionamento di questi buffer allo standar Posix il problema sparisce.
	Rif.	eGroupWare #001853.
14/10 2013	xw	25.3.0	CE	Si ha uno stack overflow durante la procedura di migrazione dati `b2f` per Egaf..
	C'era una cattiva gestione dello stack delle chiamate Lua che viene interrogato in uscita per scaricare da esso tutti i parametri tornati dalla funzione evocata ma senza che si procedesse al suo svuotamento Corretto con liblua.dll/so 1.11.0.
	Rif.	eGroupWare #001850.

25.2.0 del 09/10/2013

Data	Mod	Ver		Sintomo o Segnalazione
09/10 2013	xw	25.1.0	CE	Crash del server in importazione record da WatchDoc.
	Il problema si manifesta in un caso un po' particolare, vale a dire quando il record che viene sottoposto al salvataggio è in encoding UTF-8 e vi è associato un Trigger `beforeSave` che ha un ritorno errato. Il buffer che contiene il documento, in quel caso, viene corrotto e le successive operazioni non si erano tutelate da quella condizione.
	Rif.	eGroupWare #001841 (#001807).
26/09 2013	xw	25.1.0	CE	Crash del server in rifacimento estensione XSLT/LUA dei record di un archivio.
	L'operazione deve avvalersi della parte UD dei record ed estenderne il contenuto per collocarvi all'interno la parte XSLT/LUA calcolata. Quest'operazione più riguardare sia un aggiunta che una sostituzione (ed in alcuni casi anche la rimozione). In caso di aggunta, se la componente UD risultava vuota sino a quel momento, il buffer⁴⁾ non era doverosamente inizializzato. L'operazione presume invece che ci sia un contenuto valido così da poter ampliare tale contenuto allocando spazio a sufficienza per l'aggiunta che si andrà a fare. Anche compiendo opportunamente questo passaggio, il buffer non precedentemente inizializzato si trova ad essere di dimensione interna nulla ma punta già ad una qualche stringa (a seconda di cosa trova in memoria quando alloca). In questo modo, andando ad accodare il nuovo valore, il risultato è che si va oltre il limite del buffer realmente allocato. Corretto aggiungendo un'inizializzazione di sicurezza che mette il buffer nella giusta condizione se non inizializzato e risulta ininfluente se già inizializzato a dovere.
	Rif.	eGroupWare #001769 (#001278).
13/09 2013	xw	25.1.0	CE	La consultazione del Titolario di Classificazione di DocWay va in Loop quando si naviga la relazione 4.2.2.
	Errore piuttosto nascosto riferibile alla normalizzazione delle chiavi. La normalizzazione della chiave avveniva in tutti i casi ma per la chiave usata per le operazioni di accesso su chiave greater mancava la normalizzazione del case che invece viene effettuata per le chiavi complete. In questo modo la ricerca su chiave greater che avrebbe dovuto trovare una chiave di pari radice ne trova una con radice diversa. L'applicazione non testa tale corrispondenza e prende direttamente la seconda parte della chiave che in realtà appartiene a tutt'altra relazione, causando la condizione di loop. Corretta tale normalizzazione, rimane da sistemare il comportamento applicativo seppure si tratta di un intervento tutto sommato teso a correggere un errore che in DocWay è solo teorico ma potrebbe non esserlo in altri scenari di utilizzo dei Thesaurus.
	Rif.	eGroupWare #001783.
03/09 2013	xw	25.1.0	CE	Il processo MSA va in loop nel salvare una mail.
	Il problema si manifesta in quanto uno degli allegati non presenta estensione. In questo scenario è teoricamente equivalente indicare al server, all'atto del salvataggio dell'allegato originale, che esso è del tutto privo d'estensione ovvero che l'estensione è, di fatto, un solo punto. Mentre in Windows, per la natura del trattamento delle estensioni dei file, la cosa è del tutto ininfluente, in Linux non si può dire altrettanto. Il problema si nota perché le applicazioni (ad esempio DocWay) ed MSA si comportano diversamente. DocWay indica sempre l'estensione pari al solo punto. Questo comporta, in Linux, che il file così prodotto su File System avrà un punto in coda. Supponendo di aver il file codificato numericamente come `1234.` il file corrispondente avrà sul disco un punto in coda. All'atto del caricamento dell'allegato il nome composto prevede il punto ed il file viene trovato. MSA invece opera diversamente. Invia al server il nome privo di estensione (e di punti) e quindi il server genera il file senza punto in coda e gli associa un `ID` pari a `1235`. A questo punto, quando si richiede il caricamento dell'allegato, il server non andava per il sottile e componeva erroneamente il nome del file accodando un punto d'ufficio che, come detto, risulta innoquo in Windows ma dannoso in Linux. Ora si provvede ad accodare il punto se e solo se esso figura in coda all'ID dell'allegato. La correzione apre però le porte ad una considerazione. In questo modo gli archivi potrebbero non essere del tutto portabili in quanto copiando un archivio da Linux a Windows non si avranno problemi mentre non può esser detto il contrario. Va inoltre aggiunto che DocWay, in presenza di un `ID` senza punti ne altro, invia al server un codice cifrato che non risulta essere un `ID` valido e non conduce al caricamento di alcun file. Anche avendo corretto questa scheda, l'allegato al record prodotto da MSA non sarebbe consultabile.
	Rif.	eGroupWare #001738.
30/08 2013	xw	25.1.0	CE	La cancellazione dei documenti via Watch Doc non si avvia.
	A seguito di recenti interventi per razionalizzare il comportamento del processo di Watch Doc per una molteplicità di files, introducendo anche il trattamento di file speciali cui si associa una Stored Procedure, un errore di battitura ha causato l'incapacità del server di trattare i files `.rmxml` usati per la cancellazione dei record.
	Rif.	eGroupWare #001688.

25.0.2/3 "Candidate"

Data	Mod	Ver		Sintomo o Segnalazione
28/07 2013	xw	25.0.2	CE	Si produce un Memory Leak durante il processo di trasferimento di documenti e fascicoli nell'applicazione DocWay.
	La gestione degli allegati forzava il reload di tutta la configurazione delle chiavi con grande frequenza, anzi, con una frequenza tanto elevata da impattare sulle performance e risultare al quanto fastidiosa. Avendo corretto quel difetto è saltato agli occhi come invece ci sia un problema di consumo anomalo, più che di leak proprio nella gestione delle chiavi. In particolare la coa riguarda una categoria di chiavi derivate da altre (come le estensioni della data). Quando si cercano le caratteristiche di una chiave si chiama un metodo che uha una propria cache interna tesa a rendere quanto più rapido possibile l'accesso alle informazioni per ciascuna di esse. Per farlo tiene un tree dei percorsi di chiave “risolti” ed un puntamento a “cosa” serva. Per le chiavi indicate sopra può avvenire che le informazioni inerenti la chiave derivata vengano richieste, la prima volta, prima che si richiedano dettagli sulla chiave ospitante (che nel nostro esempio è stata ovviamente dichiarata data nel file <nomearc>.conf.xml). Che cosa accade? Che la chiave è sì nell'elenco delle chiavi dichiarate ma non è ancora mai entrata a far parte della cache dei percorsi di chiave dichiarati prima della loro eventuale risoluzione. La chiave così testata viene riconosciuta come chiave di defatul e non si identifica alcuna chiave padre. Non appena, però, viene fatto uso anche una volta sola della chiave “parent” ecco che questa viene identificata nell'elenco delle chiavi dichiarate ed entra a far parte dei percorsi di chiave risolti. La chiave derivata, la prossima volta che verrà inviata alla funzione, verrà ancora riconosciuta come chiave di default (grazie alla cache ma poi troverà la propria chiave “parent”, questa volta sì, e tenterà di inserire una nuova chiave non più default (in copia). Questo andrebbe bene se la chiave non fosse già nella lista della cache delle chiavi richieste. La nuova chiave viene infatti allocata e messa in coda all'elenco delle chiavi dichiarate (o rese equivalenti a quelle dichiarate), ma essendo già nella cache come chiave di default, la prossima volta si rifà esattamente lo stesso giro. Le nuove chiavi sono tutte in coda, ma non cambiando in alcun modo la cache ogni volta si crea una nuova chiave. Risolto: ora bisogna tener conto del fatto che la cache dei percorsi dovrebbe sempre corrispondere a pieno con l'elenco delle chiavi dichiarate, così che ogni nuova chiave derivata che entra in gioco trova sin da subito, se c'è, la propria chiave parent. Bisogna fare in modo che il caricamento della struttura chiavi alimenti automaticamente anche il btree della cache che comunque deve rimaner distinto perché la stessa chiave può essere “detta” in modi diversi.
	Rif.	eGroupWare #001684.

25.0.1 "Candidate"

Emesso il 24/07/2013 per Equitalia Sud

Data	Mod	Ver		Sintomo o Segnalazione
24/07 2013	xw	25.0.1	CE	SI presenta un memory leak in Windows.
	L'indagine portata avanti con diversi strumenti non evidenzia un memory leak onnipresente ma ne abbiamo identificato uno al verificarsi di una particolare condizione di reload della configurazione del server dovuto ad un qualche cambiamento nei parametri di sitema. Questo impediva la stesura del file `xreg<annomese>.log` producendo un imponente memory leak.
	Rif.	eGroupWare #001684.
03/07 2013	xw	25.0.1	CE	La rimozione dei files temporanei è inefficace su server Linux.
	La funzione era stata riveduta con l'introduzione dei temporanei in cartelle diverse introdotta dal server 24.10. In Linux la funzione era stata mutuata da Windows senza verificare che le condizioni di ricerca di files e cartelle (.) che vanno bene in Windows risultano errate e quindi inefficaci in Linux.
	Rif.	eGroupWare #001653.
04/07 2013	xw	25.0.1	CE	La comunicazione dell'utente e del contesto causano errore.
	Questo è dovuto al datto che la dichiarazione del contesto è stata “aggiunta” in coda a quella dell'utente ed ha sino ad ora avuto una dimensione massima piuttosto contenuta. L'uso del contesto è divenuto molto comodo per passare al server, unitamente ad un'identificazione del contesto o della sessione in corso, anche informazioni supplementari riferite a diritti ed altro. Così facendo la dimensione massima diveniva un limite importante e la presenza negli `extra bytes` di caratteri considerati illeciti nel nome dell'utente ha imposto in inversione nel test e nella separazione e gestione di queste due distinte informazioni.
	Rif.	eGroupWare #001658.
01/07 2013	xw	25.0.1	CE	Si ha una segnalazione di Disk Quota Exceded su dischi grandi che hanno ancora molto spazio.
	Difetto di calcolo (overflow) della dimensione disponibile. Corretto ed in attesa di correzione si può inibire il controllo.
	Rif.	eGroupWare #001629.

25.0.0 "Candidate"

Emesso il 17/06/2013 per test su Studio Ferrario

Data	Mod	Ver		Sintomo o Segnalazione
17/06 2013	xw	25.0.0	CE	L'acquisizione di record da WatchDoc provoca Crash casuali del server.
	Alla ricerca di questo difetto, che dallo studio dei core rilevati presso il cliente sembra essere relativo ad una sporcatura della ram nella fase di stesura dei logs, ci siamo imbattuti in una corruzione di memoria che avviene apparentemente altrove ma che a questo punto potrebbe avere impatti di varia natura. In una delle fasi di preparazione del documento alla sua stesura si compie un'operazione di recodifica che può essere necessaria per stabilire in che file il record debba realmente essere salvato. In quel frangente il buffer veniva ricodificato ma la sua dimensione originaria risultava invariata. La ricodifica può portare tanto ad un buffer più piccolo quanto ad uno più grande con effetti ovviamente differenti: troncare l'XML risultante ovvero procedere alla copia in memoria di un area ben più grande di quella realmente allocata per lo scopo.
	Rif.	eGroupWare #001541.
04/06 2013	xw	25.0.0	NF	In alcuni casi le cartelle degli allegati sono così piene da causare degrado prestazionale.
	Introdotta una possibilità di distribuire gli allegati in directory più articolate sulla base della numerazione degli allegati stessi. La funzionalità è normalmente spenta per default ma può essere abilitata con l'uso della voce `attach.longnames` nel file di configurazione dell'archivio. La funzionalità, se abilitata, provoca la realizzazione di un archivio incompatibile col passato.
	Rif.	eGroupWare #001574.

24.14.5 del 11/06/2013

Data	Mod	Ver		Sintomo o Segnalazione
10/06 2013	xw	25.0.0	CE	Le operazioni di modifica dei documenti risultano estremamente lent.
	Il problema è dovuto ad un continuo ricaricare la configurazione dell'archivio quando si manipolano gli allegati (anche se assenti) in sede di modifica del documento. Questo comporta un lieve aggravio che su macchine poco performanti come quella del cliente che ha fatto la segnalazione divengono un rallentamento molto importante. Provveduto a fare il caricamento complessivo una sola volta evitando ogni ulteriore inutile reload
	Rif.	eGroupWare #001612.
04/06 2013	xw	25.0.0	CE	L'esportazione di documenti causa alle volte un errore di documento cancellato mentre dovrebbe limitarsi ad ignorarli.
	Il processo di esportazione ignora normalmente i documenti cancellati ma c'è un processo che viene chiamato prima di avviare la vera e propria esportazione che deve identificare il PNE del primo dei record da esportare per tipizzare il file XML prodotto. Quando il documento è cancellato si causa l'errore. Ora si reitera il tentativo di identificare un documento valido passando ai documenti successivi sino a trovarne uno valido.
	Rif.	eGroupWare #001017.
16/05 2013	xw	25.0.0	CE	In caso di archivi che concentrino in un solo fascicolo (o perché non fascicolano) un numero elevato di documenti e di allegati, la cartella che ospita questi ultimi può divenire estremamente satura, con centinaia di migliaia di files e conseguenti problemi di prestazioni.
	Rif.	eGroupWare #001574.

24.14.2 del 23/05/2013

Data	Mod	Ver		Sintomo o Segnalazione
21/05 2013	xw	24.15.0	CE	Il sistema, quando sottoposto ad ampia sollecitazione, si blocca.
	Il problema si manifesta ormai da numero si mesi e tutti i test effettuati sulla base di quanto ci era possibile valutare non avevano dato esito sino a quando, recentemente, l'introduzione di alcuni log tesi a comprendere se vi fossero problemi di trasmissione socket ha posto in evidenza come il messaggi di richiesta venga ricevuto ma poi venga trattato dal server solo dopo aver cercato di reperire informazioni inerenti la connessione dell'utente (da quale IP Address, da quanto tempo). Il numero di utenti gestiti contemporaneamente è limitato e quando esso è saturo si procede a liberare uno slot secondo la tecnica del Last Recent Used. L'implementazione di questo procedimento aveva due errori al suo interno per cui quando si doveva recuperare uno slot e quando a farlo erano diversi server, questi si “rubavano” lo slot identificato (sempre lo stesso) ad ogni piè sospinto. In questo modo potevano essere richiesti molti secondi, a volte minuti, perché il server che occupava uno slot con il proprio utente riuscisse ad usarlo prima che altri processi glie lo sottraessero da sotto ai piedi. L'intervento si limita a sanare questo difetto di implementazione garantendo che la corsa critica tra più processi non causi una simile criticità. Seguiranno ottimizzazioni visto che l'analisi del problema ha evidenziato altri punti su cui ha senso lavorare.
	Rif.	eGroupWare #001447.

24.14.2 "Windows Only"

Data	Mod	Ver		Sintomo o Segnalazione
21/05 2013	xw	24.15.0	CE	L'esportazione non avviene correttamente in assenza della dichiarazione della cartella di Share.
	Il problema si manifesta a causa di quanto fatto con l'intervento eGW001447 nel quale si tiene sì conto della possibilità che la directory di Share non sia stata configurata ma si finisce col comporre male il nome della directory dei temporanei ove porre l'esportazione. In pratica, quindi, il file veniva sì creato ma in una posizione errata, tendenzialmente la radice del disco candidato.
	Rif.	eGroupWare #001585.
21/05 2013	xw	24.15.0	CE	Il Trigger di controllo delle selezioni non può applicare una clausola `<?THEN?>`.
	Difetto dovuto al fatto che il Trigger veniva evocato per ciascuna singola porzione di selezione e non nella sua interezza. Spostando il punto di intervento del Trigger si risolve il problema e si amplia la capacità di intervento del Trigger stesso.
	Rif.	eGroupWare #001565.
20/05 2013	xw	24.15.0	CE	In presenza di ricerche in cascata ordinata si spende un sacco di tempo per ordinamenti inutili.
	L'ordinamento veniva applicato a tutte le singole ricerche compiute seppure la sola che verrà tornata al richiedente è l'ultima della lista. Inibito l'ordinamento per tutte le fasi intermedie.
	Rif.	eGroupWare #A00629.

24.14.0 del 29/04/2013

Data	Mod	Ver		Sintomo o Segnalazione
24/04 2013	xw	24.13.0	CE	In presenza di nomi di files con caratteri particolari (spazi, parentesi) si hanno alle volte problemi di reperimento dell'allegato una volta assegnato ad un record.
	Il problema è legato alle modalità con le quali si costituisce l'estensione di ogni nuovo allegato, prendendo quanto segue il primo o l'ultimo punto. Quando si assume il primo, per sopperire ai casi di doppia estensione⁵⁾ l'algoritmo prendeva quanto veniva trovato senza riguardo. Ora si stabilisce, operando da destra, quale parte dell'intero nome del file possa ragionevolmente essere sottoposta a controllo accettando solo lettere e numeri (oltre ai punti ovviamente). Sulla parte residua si stabilisce quale possa essere considerata estensione. In assenza di informazioni inerenti il `MIME Type` del file o un elenco di estensioni lecite, questo metodo, seppure euristico, offre maggiori garanzie di correttezza.
	Rif.	eGroupWare #001551.
18/04 2013	xw	24.13.0	CE	Alcune lavorazioni LUA (Triggers & Stored Procedurs) non hanno luogo come dovrebbero.
	I test hanno prima evidenziato che il problema si manifesta solo col server Release mentre il server Debug ha un funzionamento corretto. In seguito è stato possibile rilevare che l'errore è dovuto ad una variabile non inizializzata che in Debug viene impostata con un valore `non nullo` che consentiva il corretto svolgimento dell'operazione.
	Rif.	eGroupWare #001512.
16/04 2013	xw	24.13.0	CE	Imperfetta gestione delle raccolte.
	Con l'introduzione delle selezioni in Ram il passaggio da selezione a raccolta poteva fallire in quanto il file temporaneo previsto non è realmente presente. Compiuti interventi per implementare la possibilità di copiare una selezione su altro file anche se questa è completamente in Ram.
	Rif.	eGroupWare #001531.
12/04 2013	xw	24.13.0	CE	Una scorretta configurazione dei seriali non viene evidenziata in fase di apertura d'archivio e conduce ad altri errori più seri anche perché in parte silenziosi in sede di inserimento documenti.
	L'incompleta configurazione dei seriali veniva trattata male e l'errore non si propagava come avrebbe dovuto. Questo comporta il fatto che l'archivio si apre ed è usabile ma che all'atto di un nuovo inserimento o comunque dell'assegnazione di un seriale, il problema si manifesta. Corretto.
	Rif.	eGroupWare #001536.

24.12.0 del 08/04/2013

Data	Mod	Ver		Sintomo o Segnalazione
28?/02 2013	xw	24.11.0	CE	I raffinamenti danno tutti “Errore di Apertura”.
	L'introduzione del nuovo sistema di denominazione delle selezioni porta con se un Side Effect in quanto il nome del file, contenendo un carattere `~` ma venendo trattati come campi “multivalore”, causano il taglio di tale nome con ll conseguente tentativo di aprire un file che non esiste. Modificato il trattamento dei separatori nell'identificazione del contenuto della ricerca nel caso speciale dei campi che iniziano con `?` in quanto tutti campi destinati al trattamento in modalità “monovalore”.
	Rif.	eGroupWare #001513.
28?/02 2013	xw	24.11.0	NC	Modellare in modo più versatile la gestione dei temporanei.
	Rimossi i temporanei `3rl…` che terminano immediatamente il loro scopo e quindi non necessitano di “sopravvivere. Modificato il sistema di gestione dei temporanei in memoria in modo che si possa modellare, oltre al numero di `slot` da gestire (e quindi il numero massimo di selezioni contemporaneamente esistenti), anche la dimensione in RAM condivisa di ciascuno `slot`. Si veda File di profilo xw.ini alle voci `TmpShmSlots` e `TmpShmSlotSize` della sezione `hs`. Suddivisa in cartelle l'area destinata ai temporanei. Ora ciascuna cartella ospita sino ad un massimo di 1000 files.
	Rif.	eGroupWare #001447.

24.10.0 del 27/02/2013

Data	Mod	Ver		Sintomo o Segnalazione
12/02 2013	xw	24.9.0	NC	Di fronte ad un considerevole carico si ottengono blocchi del funzionamento a dispetto dei più recenti interventi compiuti.
	Si presenta un comportamento anomalo dovuto al trattamento dei logs. Quando l'attività è così elevata da causare un flusso di log che il thread a ciò preposto non riesce a smaltire in tempo utile, il server finisce col mettersi in attesa della disponibilità di uno “slot” disponibile per fare log. La cosa può ripetersi più e più volte causando una sostanziale serializzazione. Ampliata la coda dei messaggi da inviare al servizio xwls, ora disponibile anche su postazione differente, e scartati direttamente tutti i messaggi che non è possibile inviare a causa del carico. Nel primo messaggio successivo inviato con successo si produrrà traccia di quanti messaggi siano stati scartati. Si veda File di profilo xw.ini alla voce `LogIp` della sezione `HsTcp`.
	Rif.	eGroupWare #001447.
21/02 2013	xw	24.9.0	NC	Se un titolo o un ordinamento richiesto non trovano riscontro nel titolo base non si ha evidenza della causa del problema.
	Introdotta una voce di log (che richiede un livello di log di 160, sopra lo standard) che indica quale sia la componente del titolo richiesto che non trova riscontro nel titolo di base.
	Rif.	eGroupWare #001494.
20/02 2013	xw	24.9.0	NC	L'esportazione di un vocabolario con filtro su una selezione⁶⁾ esporta più chiavi del previsto.
	L'errore è dovuto al fatto che la frequenza minima impostata di default era pari a '0' anziché a '1' e questo faceva esportare anche tutte le chiavi che l'analisi spettrale escludeva (chiavi valide ma con frequenza azzerata) Cambiato il valore di default a '1' mantenendo la possibilità di impostarlo a '0' col parametro 'num' del comando XML.
	Rif.	eGroupWare #001491.
15/02 2013	xw	24.9.0	NC	Le selezioni contengono tutte le parole oggetto di selezione anche queste non vengono mai usate così come il Client che le riceve non ne fa alcun uso.
	Invertito il default. Ora il richiedente deve esplicitamente domandare che gli vengano tornate le chiavi oggetto di selezione. Questo avviene, per contro, solo nel caso di selezioni vuote nelle quali i termini oggetto di selezione possono essere funzionali all'identificazione di altri termini affini secondo la logica del “forse stavi cercando…”.
	Rif.	eGroupWare #001447.
12/02 2013	xw	24.9.0	NF	Un imponente mole di operazioni causa la creazione di un imponente numero di files temporanei, spesso di piccole dimensioni. L'attività di I/O a ciò correlata può risultare particolarmente onerosa.
	Compiuta una revisione completa della gestione dei file temporanei. Essi ora vengono scaricati su disco se e solo se superano una soglia minima (4KB) e si provvede ad un sistema di rotazione concepito per garantire che la cartella del disco che ospita i temporanei non ne presenti mai in numero eccessivo. Il numero di slot da 4KB in memoria è configurabile, si veda File di profilo xw.ini alla voce `TmpShmSlots` della sezione `hs`. Durante la fase di revisione di queste componenti si è passati dalla versione `1.38` alla versione `1.48` di `boost`.
	Rif.	eGroupWare #001447.
??/02 2013	xw	24.9.0	CE	Quando il server opera su una porta no standard non vengono loggati i messaggi prodotti nell'ambito Lua (Stored & Triggers).
	I metodi usati prevedevano che si potesse indicare quale porta usare per fare il log ma di fatto, se essa non era stata preventivamente aperta, il log veniva ignorato. Dal momento che d'ufficio si apriva sempre quella con il valore di default, ogni ulteriore log veniva ignorato. Ora, se si richiede di fare log su porta specifica, essa viene generata se assente e si mantiene un pool di porta disponibili per il log.

24.8.0 del 07/02/2013

Data	Mod	Ver		Sintomo o Segnalazione
01/02 2013	xw	24.7.2	CE	L'impostazione di chiave empty effettuata su un canale che è, a sua volta una chiave alias non ha effetto.
	La verifica della chiave su cui popolare un vocabolario empty veniva fatta sulla base del percorso XML identificato senza tener conto opportunamente dell'effettiva chiave alias. In questo modo si finiva col tentare la popolazione di un vocabolario che non solo non esisteva e veniva creato ugualmente per ospitare la chiave nulla, ma non doveva proprio esistere, non ne era prevista l'esistenza. La ricerca sul vocabolario atteso, in fine, non produceva il risultato voluto in quanto, pur opportunamente configurato come vocabolario con chiave empty, tale chiave non era mai presente. Vds Configurazione degli archivi alla voce inerente la configurazione `empty_key`. Comportamento del tutto analogo per le chiavi frutto di collate sulle quali vige l'identico limite ed alle quali è stata apportata analoga correzione.
	Rif.	eGroupWare #001473, #001452.
31/01 2013	xw	24.7.2	NF	Servono Nuovi Tiggers per sopperire a limiti della struttura del documento XML.
	Introdotti nuovi triggers per effettuare l'estensione di un documento senza dover usare `xslt`. Per evocare tale trigger indicare nell'attributo `ud_xslt` della configurazione del `primary_node` la stringa `lua`. Ciò comporta l'uso del trigger `onExtend`, ovvero `<primary_node>.onExtend`. Introdotti altri 2 trigger che interessano il caricamento di un documento per farne la cache dei titoli ovvero per compiere un ordinamento. Essi rispondono all'evento `onTitle` e `onSort` ovviamente declinabili come `<primary_node>.onTitle` e `<primary_node>.onSort`. In questo modo è possibile citare nella regola di composizione dei titoli o dell'ordinamento parti di documento in realtà inesistenti ma realizzate ad hoc. Inoltre, se queste finalità non sono legate in alcun modo all'indicizzazione, l'uso di questi trigger può evitare l'uso del trigger `onExtend` ovvero dell'estensione `xslt` del documento. Nell'ambito di questo sviluppo corretto un errore “storico” inerente la lentezza della costituzione del catalogo in presenza di estensione `xslt` da sempre imputata all'elaborazione da compiere ed ora invece risolta.
	Rif.	eGroupWare #001476, #001479.
31/01 2013	xw	24.7.2	CE	Comandi di navigazione relazioni falliscono per mancato accesso ad un file temporaneo.
	Il problema si manifesta in quanto il file temporaneo usato in quel caso non veniva scritto su disco rimanendo in Ram.
	Rif.	eGroupWare #001469.
28/01 2013	xw	24.7.2	NF	Le indicizzazioni differenziali (modifiche) sono molto lente con archivi di grandi dimensioni.
	Reintrodotta l'indicizzazione lazy seppure in modo molto differente dal passato. Ora il server sa quali archivi deve monitorare indipendentemente dal fiel di configurazione (investigando direttamente la presenza delle cartelle <nomarchivio>.lazy) e la stesura del comando indicizzazione di un documento avviene scaricando le chiavi già pronte e calcolate prima di agire sulla terna dei file degli indici. Il processo lazy non deve far altro che intervenire con gradualità e può operare una chiave alla volta. L'implementazione deve considerarsi ancora in fase di test ma i primi risultati hanno dato esiti incoraggianti. Da notare che il beneficio non si nota su archivi di piccole dimensioni o con catene molto brevi ove, al contrario, la performance appare decadere.
	Rif.	eGroupWare #001447.
10/01 2013	xw	24.7.2	NF	E' utile poter ordinare una selezione ereditando i criteri di ordinamento da altra selezione esistente.
	Introdotta una nuova funzionalità di ordinamento per la quale, indicando come parametro d'ordinamento la stringa … `?SEL:<selection_id>` …la selezione effettuata verrà ordinata nello stesso modo.

24.6.0 del 14/12/2012

Data	Mod	Ver		Sintomo o Segnalazione
14/12 2012	xw	24.5.4	CE	Gli allegati di un archivi, anche se inseriti a dovere, rimangono nell'area di parcheggio.
	L'effetto è dovuto alla mancanza o alla cattiva configurazione del file di contesto. Dal momento che la sua presenza formale è rimasta invariata, nonostante tutto, in tutti questi anni, in assenza della dichiarazione nel contesto si provvede a forzare il valore del namespace necessario al trattamento degli allegati.
	Rif.	eGroupWare #001458.
07/12 2012	xw	24.5.4	CE	Alcune operazioni di esportazione falliscono perché il nome del file di export non viene creato.
	Il processo di determinazione di un nome di file temporaneo, di share o altro, dipende da un singolo metodo che calcola il percorso da applicare. Questo metodo non teneva correttamente conto del caso in cui la directory di Share non fosse stata doverosamente indicata ed in quel caso, in modo casuale, incollava in coda al percorso correttamente calcolato dei caratteri spuri.
	Rif.	eGroupWare #001447.
29/11 2012	xw	24.5.2	CE	Se si compie un'operazione di raffinamento o combinazione di selezioni, il reverse dei termini oggetto della selezione in ciascuna di esse viene perso.
	Per questo tipo di chiavi, la cui appartenenza ad uno specifico campo non è nota, si ammette il reverse “d'ufficio”. Potrebbe provocare falsi positivi, ma certo evita il rumore. In caso di falsi positivi si dovrà provvedere a concepire un più accurato sistema di hilight.
	Rif.	eGroupWare #001451.
28/11 2012	xw	24.5.1	NF	Ampliare la ricerca per proiezione in modo che operi anche senza una selezione corrente e tenendo conto di limiti sulla frequenza.
	La sintassi esistente è stata ampliata. Consultare la documentazione per maggiori dettagli.
	Rif.	eGroupWare #A02477.
22/11 2012	xw	24.5.1	CE	Alcuni casi di ricerca “as is” falliscono o, quanto meno, hanno un comportamento incongruo non rilevando tutti i documenti previsti.
	Il problema è dovuto al comportamento dell'adiacenza in presenza di iWords dei termini degli attributi tutti con la stessa posizione. In quel caso, la funzione di ordinamento delle chiavi da confrontare trova distanze identiche, condizione teoricamente non problematica, e non sa dire in quale ordine esse siano, dicendo che sono equivalenti. Visto però che la posizione, che normalmente ha senso, in questo caso ne è priva, il risultato è che l'ordine delle chiavi riferite ai termini della stessa istanza di un attributo è casuale e non consente di dare una risposta corretta. Aggiungendo un ulteriore confronto sull'ordine delle chiavi quando l'ordine delle parole è lo stesso la risposta torna ad essere corretta risolvendo quest'aspetto. Bisogna altresì sottolineare che questa soluzione non è da considerarsi completamente esaustiva in quanto offre la possibilità di dare una risposta congruente ma mantiene un certo margine di rischio in quanto a falsi positivi⁷⁾, comportamento comunque maggiormente tollerabile rispetto al silenzio che si aveva prima della correzione. In sostanza la ricerca in adiacenza su termini appartenenti ad un attributo trattato per singole chiavi non può garantire l'ordine ne la distanza, può al più approssimarla. Nota: Questo comportamento risulta varitato rispetto a prima in quanto per il server 24 il comportamento di default è quello di considerare gli attributi con iWords omogenee, comportamento che è l'inverso dei server sino al 22. Con l'introduzione di questa correzione, anche attributi con iWords non posizionali verranno ricercati correttamente.
	Rif.	eGroupWare #001448.
22/11 2012	xw	24.5.1	NF	Avendo introdotto Plug-In e Stored Procedure si è costretti ad indicare un comando “0” nell'XML col quale si richiede al server una simile attività.
	In assenza di comando valido ora si assume che il comando sia automaticamente il comando “0”.
	Rif.	eGroupWare #A02548.

24.4.0 del 15/11/2012

Data	Mod	Ver		Sintomo o Segnalazione
21/09 2012	xw	24.3.1	CE	In presenza di caratteri accentati in un vocabolario, l'accesso ai suoi contenuti tramite Tree di template voc fallisce.
	Non veniva compiuta un'adeguata transliterazione tra il testo estratto dal vocabolario e la forma del record XML che si procede a tornare. Per non rendere particolarmente complesso il trattamento della URI così prodotta da parte delle applicazioni, anziché limitarsi ad una conversione nell'encoding giusto, i termini che hanno queste caratteristiche sono convertiti in Base 64 e prefissati con un'etichetta identificativa. In questo intervento è stato inoltre limitato l'accesso alle chiavi, per i vocabolari di tipo `double`, limitatamente a quelle considerate significative, vale a dire quelle prefissate dallo spazio.
	Rif.	eGroupWare #001396.
21/09 2012	xw	24.3.1	CE	La presenza di caratteri accentati o comunque strani in un nome allegato può renderelo irreperibile.
	Il problema dipende dal fatto che il server ha il dovere di salvaguardare tutte le estensioni di un allegato e non solo l'ultima per poter gestire situazioni come file di tipo `.pdf.p7m`. Questo ha causato la necessità di considerare estensione tutto quello che segue il primo punto incontrato da sinistra anziché quanto segue l'ultimo punto da destra. In tal caso, la presenza di caratteri non correttamente gestiti dai file system causa la creazione del file ma la sua successiva irreperibilità in quanto il file system trasforma il carattere indicato all'atto della creazione.
20/09 2012	xw	24.3.1	CE	La cancellazione documenti causa un crash.
	Side effect introdotto dai Triggers che vengono chiamati in sede di caricamento e salvataggio dei documenti. In assenza del “documento nuovo” che si ha quando si salva⁸⁾ alcuni passaggi della preparazione alla chiamata dei Trigger facevano affidamento a puntatori che erano nulli. Inibito l'uso di uno dei due Trigger esistenti e modificato l'altro. Si devono produrre, col tempo, Trigger specifici per la cancellazione.
	Rif.	eGroupWare #001401.
11/07 2012	xw	24.3.0 22.1.3.8 23.1.0	CE	La presenza di Processing instruction nei documenti può causare un comportamento non corretto in sede di indicizzazione.
	Errore nel parser delle Processing Instruction e nel loro trattamento in sede d'indicizzazione.
	Rif.	eGroupWare #001361.
06/06 2012	xwls	1.7.0	CE	Il log di sistema si popola di registrazioni che non erano richieste.
	Nonostante la configurazione del modulo `xwls` consenta di indicare quali logs registrare nel `syslog`, alcuni di essi (messaggi `M` e log `L`) venivano inviati d'ufficio anche se la cosa non era affatto necessaria. Modificato il comportamento di `xwls` in modo che rispetti in maniera più puntuale le disposizioni ricevute faccia logs dei codici I/M/L⁹⁾ solo se opportunamente configurato.
	Rif.	eGroupWare #001345.
04/06 2012	libtree	1.0.0	NF	Filtri sugli alberi dinamici.
	Introdotta la possibilità di applicare all'analisi spettrale su cui si basano gli alberi dinamici anche un ulteriore filtro rappresentato da una ricerca precedente. L'esito della navigazione dell'albero saranno nodi opportunamente filtrati. Si ricorda che, poiché la loro `action` citerà una selezione esistente come propria componente, l'usabilità di questi nodi sarà vincolata alla persistenza della precedente selezione.
	Rif.	eGroupWare #001342.
01/06 2012	libxwlod/libtree	1.0.0	NF	Alberi dinamici.
	Introdotta la gestione degli alberi a nodi dinamici, o template, basati sui vocabolari.
	Rif.	eGroupWare #A01535.
24/05 2012	xw	24.3.0 24.2.2	CE	Saltuariamente un server torna indicazione di saturazione del disco.
	L'errore è causato da alcuni comandi che, pur non citando un archivio su cui operare utilizzano la componente Mess.archivio per mettere un qualche altro dato che, se utilizzato come nome di file, porta ad un file inaccessibile e ad un fallimento del test. Compiuto un duplice intervento: ora non viene ammesso il comando MSG_ACCOUNT ne qualsiasi ulteriore comando che citi una stringa non nulla nella componente Mess.archivio ma che non corrisponde ad alcun file/directory. Inoltre, se il test fallisce, il processo è concepito per fallire in tutte le successive operazioni.
	Rif.	eGroupWare #001330.
18/05 2012	xw	24.3.0.0	NF	Ampliamento funzionalità della Cache dei documenti.
	Per andare incontro alle più ampie esigenze dello sviluppo del prodotto DocWay4 la Cache dei documenti così come attualmente disponibile non è più uno strumento adeguato, si necessita di qualcosa di più evoluto. L'evoluzione più naturale consiste nell'applicare un foglio di stile XSL al documento per estrarne un… estratto che rappresenti quel che serve all'applicazione, con tutta la “logica” che ne può derivare. Implementato un metodo che consente di calcolare questa ulteriore Cache e sfruttarla in sede di richiesta titoli. Per calcolare quest'estensione si deve aggiungere un nuovo profilo title.xsl che indichi il nome¹⁰⁾ del file XSL da applicare. L'esito della lavorazione, effettuata near on line come tutti gli altri titoli, viene salvata in una nuova coppia di files (<nomearchivio>.tipxsl e <nomearchivio>.titxsl) e viene tornata nel titolo stesso quando in esso viene richiesta la colonna `TITXSL`. La porzione di titolo che racchiude questo speciale contenuto inizia e finisce col carattere `0x0C`, così da poter essere riconosciuta inequivocabilmente. Per fruirne opportunamente si deve usare un WS o un'applicazione aggiornata.
	Rif.	eGroupWare #A02506.
16/04 2012	xw	24.3.0.0	CE	Errore in cancellazione documento.
	Il documento non veniva cancellato in quanto il test supplementare inerente la modifica dei documenti veniva compiuto anche in sede di rimozione, quando il “documento nuovo” non esiste.
	Rif.	eGroupWare #001299.
16/04 2012	xw	24.3.0.0 22.1.3.5 21.2.1.26	CE	In presenza di ricerca per adiacenza su bacini di pescaggio in or tra di loro si ha un risultato errato.
	Il concetto di bacino di pescaggio è un concetto che può essere esplicito o implicito. E' implicito quando si pongono in adiacenza i valori di due attributi di un elemento o un attributo con il valore del suo elemento. In tal caso il bacino di pescaggio, rappresentato appunto dall'elemento, viene desunto automaticamente. Negli altri casi, ovvero quando il bacino da usare sia più ampio ¹¹⁾ esso va esplicitato nella frase di ricerca. L'errore in esame interessa proprio questo caso. Vediamo cosa stiamo affrontando: abbiamo una frase di ricerca con parentesi che si suddivide in due parti on `OR` tra di loro. In ciascuna c'è una dichiarazione di adiacenza tra campi per i quali si esplicita un bacino di pescaggio di livello superiore. I campi, diciamo `A` e `B` in ciascuna metà dell'espressione, sono gli stessi ed il valore del campo `A` è lo stesso. Il server compie una serie di operazioni e di verifiche per stabilire quando un'espressione d'adiacenza si possa/debba dire conclusa ma in questo caso, per due ragioni distinte, non lo faceva. La prima è che se la presenza delle parentesi veniva presa in esame, gli operatori di uguaglianza tra un campo ed il suo valore interrompevano erroneamente la ricerca di operatori come `OR` che ovviamente spezzano la condizione d'adiacenza. Il secondo, più nascosto, causava l'interpretazione dell'adiacenza come un unica espressione a causa del fatto che il bacino esplicito non veniva correttamente preso in considerazione per valutare quando si doveva aprire un nuovo “gruppo” d'adiacenza. Due interventi mirati hanno risolto l'errore.
	Rif.	eGroupWare #001297.

24.2.0.0 del 10/04/2012

Data	Mod	Ver		Sintomo o Segnalazione
02/04 2012	xw	24.2.0.0 22.1.3.4	CE	Il procedimento di Search & Replace da errore in presenza di caratteri particolari nei testi da usare per la sostituzione.
	Per compiere la sostituzione, il procedimento di Search & Replace genera un XSTL a partire da un template. Il testo da sostituire e quello che lo sostituirà sono però soggetti ad interpretazione quindi, se posti in una select la presenza di doppi apici ma soprattutto di singoli apici impatta con la sintassi XSLT. Introdotte due variabili che ci consentono di esprimere tali caratteri senza limitazioni ed usate le due variabili per la sostituzione.
	Rif.	eGroupWare #001206.
22/03 2012	xw	24.2.0.0	CE	E' stato rilevato che ci sono procedimenti consentiti dal Web Service che violano potenzialmente l'integrità dei documenti.
	Il Web Service consente di salvare un documento in modifica pur non avendo provveduto ad un precedente lock del documento stesso. In pratica è possibile caricare un documento, modificarlo dal lato applicativo e dopo un tempo indefinito, durante il quale altri operatori possono essere intervenuti sullo stesso record, procedere ad un salvataggio. Poiché il salvataggio non possiede un codice di lock, il Web Service provvede a caricare il documento bloccato per farsi dare il codice di lock ed una volta ottenuto lo applica alla copia del documento sino a qual momento frutto di elaborazione. E' quindi ovvio il rischio che le modifiche apportate da altri operatori vadano del tutto perse senza alcuna verifica se pure senza intenzioni maliziose. Per ovviare a questo comportamento il server introduce un controllo supplementare basato sul checksum del documento stesso e consente la modifica del documento non solo se il codice di lock e corretto ma anche se il checksum dichiarato in sede di modifica corrisponde a quello del documento in essere. Questo ci dimostra che il documento non ha subito modifiche da quando è stato caricato. C'è una tolleranza per quei record che risultino privi di checksum in quanto acquisiti durante la costituzione della Mappa dell'archivio e mai modificati in seguito. Per consentire, in fine, di realizzare applicazioni che rilassino questo vincolo (assumendosi le responsabilità di quello che viene fatto) si può operare a livello di configurazione degli archivi agendo sul parametro arc.allownonstrict.
	Rif.	eGroupWare #001283.
16/03 2012	xw	24.2.0.0 22.3.1.4	CE	Problemi di corruzione indici.
	L'analisi del problema evidenzia un caso relativamente singolare. Documenti inseriti nell'archivio presentano dei caratteri che possiamo definire spuri. Tali caratteri sono - - - - - A tali caratteri non corrisponde un carattere valido ne in encoding windows-1252 ne in Unicode¹²⁾. In precedenza venivano evidenziati convertendoli in un codice 0xF7xx per assicurarsi che risultassero caratteri non gestiti, ma questo non tiene conto del fatto che in alcuni casi la codifica contiene già il carattere come singolo byte di quel valore. Il risultato è che un documento che viene inserito con un carattere `0x9d` e poi viene modificato rimuovendone i contenuti errati produceva un errore di indicizzazione in quanto lo stesso carattere veniva codificato come 0xF79D quando il documento è stato inserito e come 0x9D quando è stato modificato. Riunificate le modalità di codifica di questi caratteri¹³⁾ al fine di abbattere simili casi di incongruenza.
	Rif.	eGroupWare #001273.
12/03 2012	xw	24.2.0.0	CE	Problemi di corruzione indici.
	L'analisi del problema evidenzia un caso già trattato con la segnalazione eGW001083. Non c'è ragione che il problema si manifesti ulteriormente ed è legato al caso delle iWords degli attributi tutte uguali. Modificata la modalità di “alerting” degli indici in modo che li consideri corrotti solo se realmente deve. Il solo caso superstite è quello in cui si cerca di togliere da una catena un termine che neppure c'è.
	Rif.	eGroupWare #001259.
09/03 2012	xw	24.2.0.0	CE	Impostare la regola di ordinamento nei Nodi degli alberi.
	Per risolvere la questione adottando un procedimento riusabile e pratico è stato introdotto un modificatore della frase di ricerca che consente di esplicitare la regola di ordinamento direttamente nella selezione. Per farlo si deve adottare la sintassi… `[?SORT:Regola di ordinamento]` Esiste un ordine di valutazione. In primo luogo si tiene conto dell'ordinamento nella modalità standard, vale a dire come parte estesa del comando di selezione. In sua assenza si prende quello indicato nella ricerca con il modificatore appena descritto e se nessuno dei due è presente si verifica se l'archivio ha un ordinamento di default¹⁴⁾. Se nessuno di questi stili è previsto la selezione rimena in ordine naturale¹⁵⁾ e non viene ordinata.
	Rif.	eGroupWare #001251.
01/03 2012	xw	24.2.0.0	CE	Inibire problemi sugli archivi derivanti dalla saturazione dei dischi.
	Per tutelarsi dal rischio di saturare il disco si compie un controllo di quando in quando (come si fa per la licenza) sul disco sul quale si sta per procedere con un'operazione. Se lo spazio disponibile è inferiore ad una soglia profilabile (ma comunque non superiore ai 4GB) l'operazione viene negata.
	Rif.	eGroupWare #001257.

24.0.0.0 del 22/02/2012

Data	Mod	Ver		Sintomo o Segnalazione
21/02 2012	xw	24.0.0.0	CE	Intervenire per bloccare le ricerche di lungo corso e dar loro un tempo massimo di esecuzione.
	Le ricerche vengono limitate nel tempo per evitare che esse si trasformino in un pericolosa fonte di denial of service. Per tale ragione, da sempre, esiste un limite temporale oltre il quale le ricerche effettuate dagli utenti (non si applica alle ricerche “interne”) vengono interrotte. Tale limite temporale si diversifica tra utenti standard ed utenti avanzati cui è concesso di eseguire ricerche “più lunghe”. Il valore di quest'impostazione è da sempre stato fisso: 1 minuto per le ricerche base, 10 minuti per le ricerche estese. Al fine di rendere profilabile questi tempi sono state introdotte due nuove voci di profilo: - search.maxSearchTime : indica il tempo massimo in secondi di ricerca per gli utenti standard. Il valore di default rimane di 60”; - search.maxLongSearchTime : indica il tempo massimo in secondi di ricerca per gli utenti con diritti estesi. Il valore di default rimane di 600“.
	Rif.	eGroupWare #001247.
17/02 2012	xw	24.0.0.0	CE	La ricerca globale sull'applicazione REvoluTIon non funziona.
	Al fine di verificare se un percorso XML contenente Wild Cards sia corrispondente ad uno dei percorsi di chiave del server si chiama in causa la funzione WildEqual la quale compie una riduzione a minuscolo del contenuto della stringa. Dal momento che si fa un doppio accesso al vocabolario, la chiave letta va ripristinata ma essendo minuscola il ripristino non aveva luogo correttamente. Provvedendo a salvare copia della chiave prima del test di corrispondenza il problema si risolve.
	Rif.	eGroupWare #A000629.
15/02 2012	xw	24.0.0.0	CE	Una procedura di aggiornamento dei documenti causa una corruzione di indici inspiegabile.
	Il difetto va ricercato nel fatto che la versione 24 (e la 23 prima di lei) ha un diverso modo per compiere il caricamento/trattamento dei documenti che devono essere soggetti ad indicizzazione. La versione 22 era già stata sistemata in tal senso mentre per la 23 l'accorgimento che nella 22 era stato preso è andato perso durante il porting. Forzando la conversione dei contenuti a WinLatin1¹⁶⁾ si ottiene la conversione anche delle entity numeriche. Esse solitamente servono ad esprimere valori Unicode che non rientrano nel set di caratteri adottato ma se invece puntano proprio ad un simile carattere ecco che la conversione non ha luogo in modo corretto e si rischia, pur di fronte allo stesso testo, di indicizzare in modo errato un documento. L'esempio era in un carattere illecito, anche per WinLatin1, che nel documento preesistente (che viene caricato e ricodificato) viene rimosso mentre nel documento entrante rimane nella forma di entity numerica.
	Rif.	eGroupWare #A000629.
27/01 2012	xw	24.0.0.0	CE	Una selezione non da l'esito atteso. Viene impostata un'estensione e la stoplist nulla.
	Il problema sta nel fatto che la stoplist non viene gestita in modo coerente. Si tiene sempre l'ultima caricata quindi, ora che la stoplist può essere applicata ai singoli campi, si fa un po' di confusione. Nel nostro caso si cerca su un campo, esteso per genere e numero, al quale è stata rimossa la stoplist¹⁷⁾, poi si mette questo in AND con un'altro campo per il quale si usa la stoplist di default. Così facendo, quando in un momento successivo si va ad estendere per genere e numero quanto estratto dal primo campo, la stoplist è attiva anziché disabilitata (perché è stata riattivata col trattamento secondo campo). Il sintomo più evidente si ha invertendo i campi nella frase di ricerca. Ponendo per ultimo il campo in cui si esclude la stoplist e si fa l'estensione, quest'ultima avviene con una corretta impostazione di stoplist (visto che nessun'ulteriore campo interviene a modificarla) e l'esito è corretto. Per ovviare al problema ora ogni singola chiave imposta anche la propria stoplist e se la porta appresso in ogni fase successiva, compresa l'estensione. In fase di estensione ci si assicura di aver usato la stoplist adatta.
	Rif.	eGroupWare #00001233.
27/01 2012	xw	24.0.0.0	NC	Eseguendo operazioni specifiche di una DLL si perde il concetto di Selezione Corrente.
	Compiuto l'intervento di salvaguardia della selezione corrente che viene comunque ripristinata al termine delle operazioni svolte dalla DLL.
	Rif.	eGroupWare #A0000629.
23/01 2012	xw	24.0.0.0 22.3.1.4	CE	Acquisizione di documenti tramite WatchDoc in presenza di impostazioni per la tolleranza dell'encoding non sembra aver effetto.
	Il problema sta nel fatto che l'impostazione per la tolleranza dell'encoding¹⁸⁾ era stata verificata correttamente nell'ambito del trattamento dei documenti ma non degli allegati. Alla prima operazione inerente gli allevati (via WatchDoc) il difetto s' è fatto evidente.
	Rif.	eGroupWare #00001230.
20/01 2012	xw	24.0.0.0	NF	L'esportazione in forma semplificata delle unità informative non sempre si presta ad una post-lavorazione a causa di alcuni contenuti indesiderati.
	Introdotta una modalità di esportazione detta Very Simple che corrisponde a quella che si usa quando si clona un'archivio. Equivale alla modalità Simple¹⁹⁾ ma esclude tutta una serie di commenti non necessari. Si richiama con il bit 0xd del comando XML 8.
	Rif.	eGroupWare #A0002124.
09/01 2012	xw	24.0.0.0 22.3.1.4.	CE	Non si riesce a creare un archivio con un proprio file di configurazione in una directory che non appartenga alla directory 'db' di default.
	Il problema ha un duplice aspetto. Esiste un comando per la creazione di un DB con la contestuale indicazione del file di configurazione che gli va applicato. Questo comando non prevede l'indicazione di un percorso alternativo a quello di default in quanto opera solo con un nome logico. Per ragioni legate ad una compatibilità col passato, per l'obsolescenza di questi comandi che sono presumibilmente destinati ad essere rimossi o quanto meno riveduti, non si interviene direttamente sul comando suggerendo invece l'uso del metodo apposito che consente di creare un archivio in qualsiasi posizione ma che non indica il file di configurazione da usare, per poi sostituirlo in seguito. La successiva sostituzione confligge con un comportamento sempre legato alla gestione del file di configurazione e DTD d'archivio che prevede che entrambe siano correttamente gestite e presenti. Questo richiederebbe che l'archivio venisse creato tramite il Model Designer condizione che richiama il comando di cui al punto precedente e che per altro non viene utilizzata da alcun utente. Per tale ragione si modifica questo comando (quello che fa put di un nuovo file di configurazione) perché consenta l'operazione sul file di configurazione anche in assenza dell'architettura prevista a patto che non si richieda di intervenire sulla DTD (unica componente che realmente impone la presenza dell'architettura in questo caso mancante).
	Rif.	eGroupWare #00001213.
23/12 2011	xw	23.2.0.5	CE	Le operazioni che richiedono il titolo nella sua interezza hanno tempi di risposta eccessivi.
	Il problema va ricercato nel fatto che, per ragioni che ormai affondano le radici nella storia di HighWay, il titolo che si conserva può essere di dimensioni inferiori al titolo completo perché subisce una troncatura una volta raggiunti i 4Kb di dimensione. Questa pratica non ha più alcun senso e per tale ragione la differenza è stata abolita. Ora il server crea i titoli in un modo solo, completo, e questi conserva nei file a ciò prepositi ²⁰⁾. La richiesta esplicita di titoli a dimensione piena viene ora ignorata ed i progettisti delle basi dati hanno la responsabilità di dimensionare adeguatamente i titoli (o le singole parti dei titoli) in modo che non creino una Cache inutilmente estesa.
	Rif.	eGroupWare #00001203.
20/12 2011	xw	23.2.0.5	CE	La ricerca per sequenze con punti e Wild Cards non da l'esito atteso.
	Se è vero che in sede di ricerca la gestione dei separatori veniva effettuata correttamente, nell'estensione dei termini sottoposti a Wild Card o simili si faceva ancora uso dei separatori del campo “lpscm” ottenendo di trattare come separatori dei caratteri che invece erano stati espressamente esclusi da tale elenco. Si manifesta, in realtà, solo quando si interviene sui separatori di default.
	Rif.	eGroupWare #00001205.
16/12 2011	xw	23.2.0.5	CE	La ricerca fonetica non trova quanto previsto.
	Verificato uno scorretto porting della funzionalità da HighWay a eXtraWay tale per cui si compiva un'estensione “base” sulla chiave impostata ma poi si finiva con compiere una scorretta conversione per il trattamento delle doppie/singole e dell'H come carattere che può seguire ogni altro carattere.
	Rif.	eGroupWare #00001196.
06/12 2011	xw	23.2.0.5 22.3.1.3.	CE	Corruzione indici in indicizzazione differenziale.
	Identificati due diversi errori, l'uno in cascata dell'altro. Essi vanno ricondotti all'abbandono della metodica HighWay di far convergere più campi nello stesso vocabolario, che è stata originariamente abbandonata ma poi è stata ripristinata per far convergere l'XSL nell'XML. Errore #1 Caso:Esiste una chiave condivisa che interessa più porzioni diverse dello stesso documento, porzioni che vengono indicizzate in ordine (es.: il campo XML, poi il campo XSL e poi gli allegati con qualche chiave globale o un key_alias/key_also). Quando si deve indicizzare la seconda, terza, ennesima porzione non si teneva conto del fatto che la precedente fosse stata indicizzata se il contenuto della porzione che si sta per affrontare risulta invariato. In questo modo, se la componente XSLT non cambia ad un primo intervento sul documento, il suo contenuto non veniva indicizzato (ma a quel punto le posizioni dei suoi termini potevano essere errate) e ad una successiva operazione di modifica che invece risultasse modificante, le posizioni delle parole da togliere non risultavano più coerenti. L'intervento prevede che si indicizzi un campo se il suo contenuto risulta cambiato o se è stato precedentemente indicizzato un qualsiasi altro campo del documento che interessi la stessa chiave, per assicurarsi che le posizioni delle iWords vengano rettificate a dovere. Errore #2 Caso: dopo aver corretto il caso di cui al punto precedente, si ha una condizione che non si riteneva di poter più incontrare. Agendo in indicizzazione differenziale prima con quella negativa e poi con quella positiva, si assumeva che le chiavi in negativo potessero essere accodate ai riferimenti in essere (salvo controllare che non ci fosse congruenza con l'ultima chiave posizione per evitare di introdurla più volte). Se però indicizzo prima il campo XML e poi XSL (e poi gli allegati che però hanno un esplicito controllo sulla iWord raggiunta) posso imbattermi in un caso in cui la chiave negativa che sto per introdurre non è più congruente col resto (la sua posizione può risultare inferiore ad una positiva già introdotta quando si è compiuta l'operazione in positivo sul campo precedente). In quel caso la procedura di introduzione della iWord nella catena riferimenti temporanea deve tener conto di quest'aspetto ed agire come si fa con la positiva, vale a dire scandendo le posizioni dal principio (nel caso positivo si usa un “principio relativo” ma in questo è meglio agire in modo assoluto) sino a trovare il punto in cui inserirsi ovvero la posizione positiva da annullare. Si tiene conto anche del caso delle chiavi “single” per quanto sia ben poco probabile che queste creino reali problemi se non a seguito di un errore di configurazione.
	Rif.	eGroupWare #00001083.
30/11 2011	xw	23.2.0.5 22.3.1.2.	CE	Memory Leak in Search & Replace.
	Identificata e corretta con le procedure utilizzate nella correzione precedente.
	Rif.	eGroupWare #00001181.
22/11 2011	xw	23.2.0.5 22.3.0.0.	CE	Crash del server durante operazioni varie su archivio xccm.
	Il problema si presenta in modo regolare in una parte del codice concepita per alimentare un elenco interno delle caratteristiche di chiave da indicizzare. In tale condizione, in presenza di una riallocazione che non dovesse giungere a buon fine a causa di indisponibilità delle risorse della macchina, la condizione che si manteneva in essere era “sporca” in quanto risultava essere presente un certo numero di chiavi configurate se pure in realtà l'area allocata per tale scopo era nulla. I logs di giugno di un errore simile lo confermano. Modificato il server perché annulli il contatore di chiavi e quindi argini la condizione in cui il problema può manifestarsi. A fronte di una mancanza di Ram disponibile non c'è molto di più da fare.
	Rif.	eGroupWare #001176.
16/11 2011	xw	23.2.0.5.	CE	Non si riesce a fare un uso completo delle parentesi esprimendo selezioni che hanno al loro interno le sequenze <?THEN?> o <?UNION?>.
	I modificatori <?THEN?> e <?UNION?> erano considerati separatori di una sequenza di selezioni da compiere in cascata. Ora questi operatori sono in realtà identificatori di porzioni di selezione che viene automaticamente isolata sulla base delle eventuali parentesi tonde utilizzate. Esempio: L'espressione… `(frase1 <?THEN?> frase2 AND NOT <?SEL0?>) and frase3` …era precedentemente vietata a causa delle tonde, ed ora è invece accettata.
	Rif.	eGroupWare #001148.
11/11 2011	xw	23.2.0.5.	CE	Errore “Campo non trovato” modificando un documento esistente dell'archivio di Regione Veneto.
	L'archivio è praticamente una 21 (una delle prime 22 ma non regolare) non è stato ricostruito ma è stato adeguato alle esigenze del 23 (compattamento indici e reindicizzazione). I documenti però riportano un flag tipico della presenza del titolo nella componente UDD del documento. In aggiornamento di un documento, la presenza di quel flag causava errore in sede di modifica di un documento che presenti il titolo nell'UDD.
	Rif.	eGroupWare #001153.
26/10 2011	xw	23.2.0.0.	CE	L'errore in indicizzazione differenziale (modifica/cancellazione) lascia le chiavi in condizione errata.
	Introdotta una modalità che cerca comunque di sanare le altre chiavi lasciando spuria solo quella incongrua.
	Rif.	eGroupWare #001154.
25/10 2011	xw	23.2.0.0. 22.3.0.0	CE	L'indice dell'archivio rvdoc non va a buon fine. A quanto pare si ha una chiave mono valore che converge in un vocabolario multi valore, probabilmente quello della ricerca globale.
	Il problema è in realtà un po' diverso da quanto immaginato. Avendo fatto convergere il contenuto degli elementi ed attributi di XSL nei vocabolari di XML, anche le chiavi globali convergono in esse. L'archivio presenta l'indicizzazione globale di tutti i campi, un'estensione XSL e degli allegati. Gli allegati venivano erroneamente indicizzati prima di indicizzare il campo XSL. In questo modo si calcola l'iword delle parole di XML, poi degli indici ma quando si procede a calcolare quelle di XSL il numero di iword di partenza non tiene conto degli allegati. In questo modo, se una parola che converge nel vocabolario globale è presente tanto nell'allegato quanto nella componente XSL, si ha una differenza negativa tra le posizioni delle parole. Affrontato il problema rimandando l'indicizzazione degli allegati dopo che tutti i campi sono stati indicizzati correttamente. Corregge un Side Effect introdotto con la versione 22.1.3.5 del 30/06/2010.
	Rif.	eGroupWare #001154.

23.1.2.0 "Candidate"

Fornita a Regione Veneto per stress test il 20/10/2011

Data	Mod	Ver		Sintomo o Segnalazione
05/10 2011	xw	23.1.2.0	CE	Lentezza nell'alimentare e nel consumare la directory lazy.
	In primo luogo è stata realizzata una directory lazy d'archivio, denominata <nomearchivio>.lazy. In essa si trovano le sole operazioni riferite a quell'archivio, nella fattispecie parliamo di operazioni inerenti gli indici. In secondo luogo è stato compiuto un intervento teso ad accedere alle directory dei files lazy senza forzare l'ordinamento, con un processo immensamente più rapido.
	Rif.	eGroupWare #1143.

23.1.0.0 del 05/10/2011

Data	Mod	Ver		Sintomo o Segnalazione
05/10 2011	xw	23.1.0.0	CE	Esportazione in directory inattesa.
	Corretto il calcolo della directory di default per il materiale destinato all'area di Share che corrisponde ora all'area dei temporanei se non diversamente configurato.
	Rif.	eGroupWare #001137.
29/09 2011	xw	23.1.0.0 22.2.14.0	NF	Ampliare le registrazioni in XReg per salvaguardare un maggior numero di informazioni.
	Lo scopo principale del registro è quello di consentire verifiche sulle attività modificanti per un archivio e ricostruire lo stato passato dei documenti alla bisogna. A quest'esigenza si somma, alle volte, anche la necessità di compiere verifiche sullo sfruttamento dei dati e quindi conoscere chi ha consultato cosa. A tal fine, in questa sede, si consente l'ampliamento delle registrazioni in XReg secondo i seguenti criteri: In primo luogo le informazioni supplementari sono registrate a patto che si introduca nel file di configurazione un'profilo specifico (Vds. Configurazione degli archivi, voce 'arc.wide_xreg'). Una volta attivata tale modalità vengono registrate informazioni per: - Consultazione di un documento, con l'indicazione del numero fisico dello stesso; - Consultazione di un allegato, con l'indicazione del percorso completo del file caricato; - Introduzione di un nuovo allegato, con l'indicazione dell'ID+estensione che sono stati assegnati all'allegato. Si ricorda in proposito che il Server non è in grado di distinguere i casi in cui il caricamento del documento o dell'allegato abbia luogo a seguito di una richiesta dell'operatore ovvero a seguito di un automatismo dell'applicazione e/o del server stesso. Si pensi ad esempio al caso del calcolo dell'impronta, che carica tutti gli allegati anche se l'operatore non ne prende realmente visione.
	Rif.	eGroupWare #001135.
28/09 2011	xw	23.1.0.0	CE+NF	Indicando in esportazione un file XSLT da applicare alle Unità Informative da esportare, esso viene completamente ignorato. L'esportazione è poi sempre difficile da reperire a causa della collocazione dei files nella directory dei temporanei.
	Corretto il caricamento del file XSLT dal nome di file (assoluto o relativo alla posizione dell'archivio) espresso. Modificato il comportamento di base della funzione perché stabilisca la directory da considerare punto d'origine per i percorsi relativi con un criterio differente: - Prima si stabilisce se è stata configurata una directory condivisa²¹⁾ - Solo se non è stata configurata una valida directory condivisa si fa uso della directory dei temporanei.
	Rif.	eGroupWare #001137.
22/09 2011	xw	23.1.0.0	CE	I processi Unix che non fanno nulla hanno comunque un occupazione di CPU inattesa e provocano un carico del sistema innaturale.
	Compiuto un nuovo intervento sulle procedure per mezzo delle quali il server compie sleep si piattaforme Unix.
	Rif.	eGroupWare #001069.
22/09 2011	xw	23.1.0.0 22.2.15.0	CE	Nonostante gli interventi effettuati, un temporaneo di lungo corso sparisce se pur intensamente utilizzato.
	Il problema è da ricercarsi nel precedente intervento che, pur di far posto dove necessario, cancellava files anche appena candidati. Ora non accade più così, si candidano più files che verranno comunque rimossi la prossima volta.
	Rif.	eGroupWare #000933.
19/09 2011	xw	23.1.0.0 22.2.15.0	CE	Errore di accesso all'elenco chiavi di un archivio ACL tramite Viewer.
	Il problema è dovuto all'interpretazione di alcune Processing Instruction entro certi documenti. Se nella loro conformazione in “pseudo-attributi” uno di essi era nullo, il server combinava una porcheria creando percorsi di chiave dai contenuti casuali ed errati che quindi si avvertivano quando si procedeva all'interpretazione dell'XML che dichiara la struttura chiavi. Corretta l'indicizzazione delle Processing Instruction.
	Rif.	eGroupWare #001131.
14/09 2011	xw	23.1.0.0	CE	La ricerca sul campo @ non si estende automaticamente alle chiavi globali.
	La documentazione (Vedasi Configurazione degli archivi) recita da molto tempo che se non viene indicato alcun Search Alias per il campo chiocciola (@) ma sono stati configurati dei campi che popolano un vocabolario globale per almeno un'unità informativa, la ricerca viene compiuta esclusivamente su tali canali, appunto globali. I fatti smentiscono quanto detto: l'intenzione non è mai stata tradotta in realtà, sino ad ora. Adesso vale quanto promesso dalla documentazione. P.S.: Per le versioni precedenti del server si suggerisce di indicare opportunamente il Search Alias '@' esplicitando il legame con le chiavi globali, identificate dalla sequenza `XMl,/<unità_informativa>/#global`.
	Rif.	eGroupWare #001129.
13/09 2011	xw	23.1.0.0 22.2.14.0	CE	Crash del server se il file .ser.xml è vuoto.
	La realtà è un po' diversa. L'errore si manifesta non se il file è vuoto o assente bensì se è esistente, non vuoto, e se il suo contenuto non è Well Formed Xml. L'errore si era verificato presso un utente al quale il ser.xml era stato riempito di `NULL` e quindi l'XML risultante non era valido. Di fatto mi aspetto che il problema si menifesti anche se il contenuto è `simil xml` ma non well formed.
	Rif.	eGroupWare #001117.
13/09 2011	xw	23.1.0.0 22.2.14.0	CE	Il ricalcolo dell'estensione XSL di un documento, dovuta all'aggiornamento del file .xslt applicato all'Unità Informativa, non ha effetti sui titoli dei documenti.
	Al fine di realizzare un intervento semplice e quanto più possibile indolore o poco doloroso si agisce come segue: Si valuta la regola di composizione del titolo e se in essa sono presenti parti che provengono dall'estensione XSL del documenti si provvede al loro annullamento quando si rettifica l'estensione del documento. In questo modo il titolo vieie ricalcolato alla prima occasione utile.
	Rif.	eGroupWare #001118.
13/09 2011	xw	23.1.0.0	CE NF	L'uso di libiconv con ASCII//TRANSLIT da risultati incongrui.
	La prima cosa che si nota è che il carattere 'à', espresso in forma UTF-8, viene trasliterato in diverso modo da diverse piattaforme. - La iconv.dll di Windows torna la trasliterazione ”'a“; - La libiconv.so Linux torna la trasliterazione “a” se si sfrutta dal comando 'iconv' che si adegua al `locale` della macchina, variando il locale l'esito può essere nullo; - La libiconv.so Linux usata da eXtraWay non compie la trasliterazione (il `locale` evidentemente non va molto bene) e torna un '?'. Dal momento che una simile “incertezza” non è ammissibile, e non lo è neppure il diverso comportamento da piattaforma a piattaforma, si è fatto uso del set di caratteri riconosciuto dallo standard Unicode (Vedere Unicode Character Name Index) per ampliare e completare la tabella di trascodifica evitando in toto l'uso della libreria iconv.dll/libiconv.so. Il risultato dev'essere in linea col precedente, anzi superiore, e può richiedere rifacimento degli indici.
	Rif.	eGroupWare #001113.
12/09 2011	xw	23.0.6.0 22.2.14.0	CE	In alcuni casi di errore in sede di indicizzazione off-line gli indici risultano consistenti pur non essendolo.
	All'atto pratico, pur considerando la possibilità che un'indicizzazione off-line fallisca, essa non ha effettivi impatti sullo status dell'archivio. Il file '.stat' può essere registrato con dati incongruenti riferiti a chiavi per le quali potrebbero non esistere neppure i record del vocabolario e/o le catene dei riferimenti. Per ovviare a quest'inconveniente, in presenza di un difetto in sede di indicizzazione, in corrispondenza alla registrazione nel log giornale del cattivo comportamento dell'operazinone si impostano anche i flags inerenti l'inaffidabilità degli indici primari e secondari. Rimane da perfezionare il caso del singolo indice in cui sarebbe opportuno valutare se si sia corrotto un indice primario o secondario.
	Rif.	eGroupWare #001121.
09/09 2011	xw	23.0.6.0	NF	Nonostante la flessibilità sull'estensione alcuni allegati non vengono caricati.
	L'intervendo di pochi giorni or sono riguardava solo gli allegati in forma di ID implicito e non i percorsi espliciti. Estesa la correzione.
	Rif.	eGroupWare #001116.
07/09 2011	xw	23.0.6.0 22.2.14.0	CE	Il server va in crash in analisi spettrale.
	Il difetto si manifesta quando si coinvolge una catena di riferimento molto vasta, la cui dimensione supera i 2MB. In quel caso il calcolo della dimensione della parte da caricare veniva compiuto in modo errato (refuso del server 21) e si finiva col leggere molto di più di quanto non fosse stato effettivamente allocato allo scopo.
	Rif.	eGroupWare #001121.
06/09 2011	xw	23.0.6.0	NF	Non è possibile compiere il caricamento di certi allegati a causa del case della loro estensione.
	Quanto detto avviene esclusivamente sulle piattaforme Unix in cui il case dei files è diversificante, cosa che non avviene su piattaforma Windows. Il problema si manifesta quando si fa riferimento ad allegati che appartengono ad un DB in modalità differenti dal canonico upload, quindi recuperi di dati pregressi o allegati espressi in modo esplicito.
	Rif.	eGroupWare #001116.
02/09 2011	xw	23.0.6.0 22.2.14.0	CE	Non si riesce ad inserire nuovi allegati se pure si possono inserire o modificare documenti.
	Il comportamento del server è decisamente ambiguo. A rigor di logica il comportamento dovrebbe essere omogeneo, uniforme, sia per quanto riguarda inserimento/cancellazione/modifica dei documenti sia per quanto concerne analogamente gli allegati. Di fatto, da molto tempo a questa parte, il comportamento del server era lasco in materia di documenti e stringente in materia di allegati. Riportata uniformità nel comportamento scegliendo come default la modalità che comporta le minori interruzioni operative, ovvero consentendo inserimenti e modifiche di documenti ed allegati. La decisione di prendere questa via anziché quella maggiormente stringente viene dal fatto che, indipendentemente dagli indici, i valori seriali vengono registrati separatamente e quindi la loro progressività ed univocità dovrebbe essere comunque garantita. Per completezza viene introdotta una voce di profilo, `arc.trust_indexes` (Vds. Configurazione degli archivi), che consente di passare dalla modalità lasca a quella stringente.
	Rif.	eGroupWare #001083.

23.0.5.1 "Unix Only"

Data	Mod	Ver		Sintomo o Segnalazione
26/07 2011	xw	23.0.5.1	CE	Non importa documenti tramite WatchDoc.
	In presenza di un archivio per il quale non si lasci il profilo di base ma si imposti un profilo d'archivio specifico, con tanto di diritti e compagnia bella, manca la validazione dell'utente “hwadmin”. Il difetto si manifesta solo in Unix.
	Rif.	Attività per Studio Manni.

23.0.5.0

Data	Mod	Ver		Sintomo o Segnalazione
26/07 2011	xw	23.0.4.7	CE	Crash del server in salvataggio documento.
	Sulle prime ho ritenuto che il problema fosse da ricercare nel particolare contenuto di un allegato che si presenta con il BOM ed è codificato UTF-8. Ho apportato la modifica già presente nel server 22. In seguito, con i test effettuati dal segnalatore, è invece risultato evidente un difetto della costituzione dei titoli (che ha impatto durante la fase di indicizzazione del server 21) dovuto ad un erroneo sfondamento del buffer (evidenziato in Linux e non in Windows). Il difetto si era già manifestato in precedenza in modo simile, ma durante un ordinamento. Ora si è provveduto ad un ulteriore intervento inerente la costituzione dei titoli.
Rif.	eGW #001106/001107.
19/07 2011	xw	23.0.4.7	CE	Non si riescono più a recuperare gli allegati e la loro numerazione riprende da 1. I titoli dell'applicazione DocWay mostrano una stranezza nella data.
	Si tratta di una serie di side effect legati alle più recenti modifiche in materia di normalizzazione della data nei titoli e trattamento degli allegati. L'occasione è stata propizia per scoprire che non si teneva conto correttamente dei contatori degli XML e degli Allegati.
	Rif.	eGreoupWare Ticket #1102.
15/07 2011	xw	23.0.4.5	NC	La normalizzazione degli elementi data nella Cache dei titoli non è sovente funzionale allo strato applicativo.
	Rimosso il refuso HighWay che comportava la trasformazione delle date nel formato gg/mm/aaaa nella composizione della Cache in quanto essa non viene più usata come “titolo” del documento ma come preview di alcune sue parti principali. Si rimanda allo strato applicativo il compito di fare il corretto uso di tale valore e quindi di apportare la normalizzazione del caso.
	Rif.	eGreoupWare Ticket #1101.
14/07 2011	xw	23.0.4.5	CE	Compiendo la ricerca dello stesso termine sullo stesso campo ma con estensioni diverse nella stessa frase di ricerca si ha un comportamento inadeguato.
	Il problema sta nel fatto che una simile attività… non si era mai fatta. L'unico caso in cui si aveva un comportamento simile era quello in cui la stessa parola appariva in un caso con estensioni potenziali ed in un altro nella modalità as is. Calcolato in modo “predittivo” quali estensioni si applicheranno a questa chiave e considerata una singola chiave anche se presente più volte se e solo se le estensioni risultano differenti.
	Rif.	eGreoupWare Ticket #1095.
13/07 2011	xw	23.0.4.5	CE	In presenza di chiavi di percorso con caratteri aventi case non minuscolo, la struttura delle chiavi viene duplicata, presentanto sia la chiave maiuscola che quella minuscola e comportando errori in ricerca (falsi negativi).
	Difetto dovuto ad un errore di normalizzazione introdotto dal B+Tree che non teneva correttamente conto delel chiavi di percorso compiendo una normalizzazione non prevista Sostituito l'uso del btree classico con un B+Tree in Ram anche in costituzione della struttura delle chiavi d'archivio²²⁾.
	Rif.	eGreoupWare Ticket #1095.
13/07 2011	xw	23.0.4.0 22.2.12.0	CE	L'indicizzazione degli allegati alimenta il canale globale anche se non richiesto.
	Il difetto è stato introdotto con la modifica della scheda RightWay 54892 che riguardava proprio l'alimentazione del canale globale anche con i dati provenienti dagli allegati se richiesto. La correzione, a suo tempo, fu fatta molto male e causava l'alimentazione della chiave globale sempre e non solo se richiesto. Rettificato l'intervento in modo che agista sulle chiavi globali solo se correttamente configurato.
	Rif.	eGreoupWare Ticket #1093.
30/06 2011	xw	23.0.4.0 22.2.10.0	CE	La ricerca che comprenda entity xml o numeriche non viene risolta correttamente.
	Il comando di ricerca non prevede che si faccia uso di espressioni XML e si basa sul set di caratteri windows-1252 come eredità del precedente server HighWay. Analogo è il trattamento che viene fatto delle chiavi. In ricerca ci si aspetta che quello che viene inviato sia una stringa non un'espressione XML ma, di fatto, i sistemi che evocano il server non riescono a compiere un simile distinguo. Per andare loro incontro, il server ora normalizza e traduce in caratteri tutte le entity numeriche riconducibili al set windows-1252 e le 5 entity obbligatorie dell'XML che sono: & " ' < e >.
	Rif.	eGreoupWare Ticket #1085.
30/06 2011	xw	23.0.4.0	CE	L'esclusione di alcuni separatori non sembra avere effetti sull'indicizzazione.
	Pur escludendo dei separatori con il profilo dell'archivio, se essi fanno parte del set di default ereditato da HighWay essi rimangono separatori comunque. Dal momento che il metodo di integrazione dei separatori ci consente di esplicitare direttamente anche quelli, non vale la pena di prenderli in considerazione oltre e quindi vengono ignorati tenendo solo quelli dichiarati nel file di configurazione (ovvero le varianti ivi indicate rispetto all'elenco di default).
	Rif.	eGreoupWare Ticket #1080.
29/06 2011	xw	23.0.4.0 22.2.10.0	CE	Crash del server in ordinamento documenti.
	In presenza di un ordinamento che preveda l'opzione (join:add) si possono verificare condizioni d'errore in quanto il buffer di ordinamento veniva alimentato male calcolando un valore che, risultando negativo, causava uno sfondamento dello spazio utile.
	Rif.	eGreoupWare Ticket #1080.
23/06 2011	xw	23.0.4.0	CE	Il server non tratta tutti gli allegati allo stesso modo, specie in sede di rilocazione e spostamento da uno Storage ad un altro.
	Compiuto un ampio intervento che unifica il comportamento del server a fronte delle 3 diverse tipologie di allegati ammesse: - quelle espresse nell'attributo `name` dell'elemento `xw:file`; - quelle espresse nelle Processing Instuction `xw-file` nello pseudo-attributo `name`; - quelle espresse in percorsi esplicitamente dichiarati nel file di configurazione dell'archivio per mezzo dell'attributo `attach` valorizzato con i valori “yes” o “index”. Completata l'implementazione (29/06) consentendo il reperimento di allegati impliciti espressi con questa modalità.
	Rif.	eGreoupWare Ticket #1072.
21/06 2011	xw	23.0.4.0	CE	Il server va in crash in avvio in assenza di xwgl ma in presenza del suo file di configurazione e fa altrettanto in uscita ma indipendentemente da xsgl.
	Il problema di xwgl è che le condizioni descritte (c'è il file di configurazione ma manca l'eseguibile, fanno fallire l'avvio. In quella fase il thread che scrive i logs ed il registro sono già avviati ma nessuno provvede a spegnerli prima che il processo si chiuda e la memoria cui essi fanno riferimento risulta indisponibile. Per il resto il problema sta nella liberazione di una classe che boost cerca a sua volta di liberare alla fine della propria attività con risultati evidentemente errati.
	Rif.	eGreoupWare Ticket #1063.
17/06 2011	xw	23.0.4.0 22.2.9.1	CE	L'archivio `xccm` presso Selex si danneggia negli indici.
	Il crash si manifesta a causa di una sporcatura della struttura `lpArc` dopo il salvataggio del documento e prima che si provveda alla sua indicizzazione. Quasi sicuramente si tratta di un overflow non gestito. Ereditati dalla versione 23 i processi per la stesura del file .pk²³⁾ e .replay utili all'identificazione dell'errore ed alla sua riproduzione. I test dimostrano che delle differenze ci sono (nell'area UD del documento e quindi delle chiavi), ma questa procedura dovrebbe consentire di identificare l'errore.
	Rif.	eGreoupWare Ticket #1036.
16/06 2011	xw	23.0.4.0	CE	Il server, anche se del tutto inattivo, ha un consumo di CPU attorno al 4% su server Linux.
	Il problema va ricercato nel fatto che l'attività di Yield delle librerie di boost viene compiuta sulle diverse piattaforma in modo molto differente. Mentre su Windows si provvede a compiere lo Sleep di `1millisec`, su Linux si evoca una funzione di sched_yield che rilascia il time slice a disposizione. Non essendoci altra attività da compiere, però, il server viene subito riavviato e se questo rilascio del time slice avviene in un ciclo di controlli che, se non ha null'altro da fare diviene equivalente ad un loop ecco che il programma si prende una quantità di CPU assoluta, il 100%. A suo tempo si intervenne compiendo uno sleep (funzione usleep) senza rendersi conto che esso durava `1microsec` e non `1millisec`. Modificato lo sleep perché attenda `1millisec` come su Windows..
	Rif.	eGreoupWare Ticket #1069.
15/06 2011	xw	23.0.4.0 22.2.8.0	CE	Crash in indicizzazione su archivio xccm C/O Selex.
	Dalla verifica del dump si determina una corruzione del puntatore all'lpArc che ha origine già da arc_mem. Corretti alcuni buffer potenzialmente sottodimensionati nel parsing del documento.
	Rif.	eGreoupWare Ticket #1036.
14/06 2011	xw	23.0.4.0	CE	Memory leak del Server Master.
	Visti i problemi che possono sorgere con l'uso dei Mutex/Single Objects (particolarmente in Linux) si rimette in gioco la modalità “as job” per la stesura del registro. Tale modalità soffre di una certa “lentezza” se il server viene stressato sensibilmente.
	Rif.	eGreoupWare Ticket #1059.
14/06 2011	xw	23.0.4.0 22.2.8.0	NC	Ricerca per intervallo di date non efficace quando le date non prevedono mese ed anno.
	Il comportamento del server in questo caso deriva daun antico refuso. In origine, per ogni campo data, si generava una chiave <anno>0000 per ogni data indicizzata così da poter fare ricerce per il singolo anno senza dover estendere la ricerca a tutte le date di quell'anno, sfruttando quindi una sola chiave anziché, potenzialmente, 365. Questo comportamento ha trovato applicazione anche nella gestione dei Ranges per cui, indicando estremi privi di mese e giorno, il server avrebbe finito per applicare il range solo a queste chiavi particolari, includendo quindi l'anno. Si noti come l'estremo maggiore comprenda in quel modo tutto l'anno indicato anche se il valore indicato per mese e giorno è '0000'. Un simile comportamento non ha più alcun senso da quando (molte versioni or sono), sono state introdotte le chiavi #year, #ymon e #time che consentono di cercare espressamente per il singolo anno, per anno e mese e per l'orario. Tutte queste chiavi vengono derivate dal contenuto del campo data in esame. Non avendo più ragion d'essere il trattamento specifico di questa antica sintassi, c'erano alcune possibilità da prendere in esame: 1) Considerare le date non coerenti come un errore sintattico e negare la ricerca; 2) Accettare il formato privo di mese e giorno forzandone gli estremi al primo gennaio ed al 31 dicembre; 3) Tollerare il range male espresso. Di fatto il caso 1 non può essere perseguito in quanto il server è sempre stato tollerante verso le date espresse male (una data senza mese e giorni sarebbe da considerarsi espressa molto male) e dovrebbe quindi negare la ricerca a documenti che diverrebbero, in tal modo, irreperibili (ad esempio proprio per essere corretti nella data errata). Parimenti, il caso 2 non può essere perseguito in quanto campi data volutamente compilati con i valori privi di mese e giorno porterebbero ad una condizione di confusione. Non resta che il caso 3. In questo caso una data che risulti priva di mese ed giorno (e quindi espressa con 4 zeri in coda dopo il solo anno) ha una collocazione che si pone tra il 31 dicembre dell'anno precedente ed il primo gennaio dell'anno stesso (in ordine sia alfabetico che numerico) e quindi il range viene tollerato e risolto. N.B.: diversamente da quanto avveniva prima, l'estremo superiore del range espresso senza mese e giorno non comprende tutti i documenti di quell'anno bansì li esclude includendo esclusivamente i documenti nei quali la data sia stata effettivamente compilata nella stessa identica forma.
	Rif.	eGreoupWare Ticket #1064.
09/06 2011	xw	23.0.4.0 22.2.8.0	CE	Il compattamento degli indici viene effettuato anche se non richiesto.
	Il compattamento degli indici è spesso eseguito in modo più o meno automatico senza che in realtà ce ne sia reale bisogno. La Console, in sede di costituzione del catalogo, non invia al server neppure il comando che indica che non si vuole compiere il compattamento se il check box corrispondente viene smarcato. Per sanare questo comportamento altamente discutibile si abilita quanto segue: a) Si abolisce il parametro del comando di indicizzazione off-line che indica di evitare il compattamento. Il compattamento viene evitato per definizione. b) Si introduce un parametro nuovo (0x08) del comando di indicizzazione off-line per richiedere esplicitamente il compattamento, senza tale parametro il compattamento non viene eseguito. c) Il comando per il compattamento degli indici può essere richiamato singolarmente come avveniva in precedenza. La Console va modificata di conseguenza.
	Rif.	eGreoupWare Ticket #1063.
09/06 2011	xw	23.0.4.0 22.2.8.0	CE	La rimozione dei temporanei va in affanno di fronte ad operazioni massive.
	Per quanto configurata con criterio, la scelta di quanti temporanei lasciare a disposizione deve scendere a compromessi. Non si possono creare troppi temporanei altrimenti la directory che li ospita va in sofferenza ed allo stesso modo non si possono rimuovere temporanei troppo “giovani” pena difetti di funzionamento delle applicazioni. Il sistema viene arricchito riducendo la soglia di attenzione di riempimento della directory dai precedneti 64000 files agli attuali 56K files. Se questa condizione si verifica e se esistono comunque più di 48K files nella directory, il server riduce rapidamente l'intervallo di tempo che intercorre tra un test ed il successivo così da garantire che la directory non vada in saturazione. Questo tempo di test poi torna gradualmente al livello impostato, ma in pratica lo raggiunge man mano se e solo se la satuarazione della directory dei temporanei tende a normalizzarsi.
	Rif.	eGreoupWare Ticket #1058.
09/06 2011	xw	23.0.4.0 22.2.8.0	CE	Memory leak del Server Master.
	L'errore si è manifestato presso Selex e durante un'importazione massiva di documenti per Equitalia Nomos. Un'analisi del comportamento mostra che se non si stila il registro il problema non si presenta. Pur verificando passo passo il comportamento del server non mi è stato possibile identificare un caso chiaro in cui si presenti il memory leak. Compiuto comunque un intervento correttivo nei punti in cui si fa uso delle funzioni che determinano i files presenti in una directory.
	Rif.	eGreoupWare Ticket #1059.

23.0.3.0

Data	Mod	Ver		Sintomo o Segnalazione
07/06 2011	xw	23.0.2.0	NF	E' necessario poter operare sugli allegati gestendoli su Storages di diverso livello.
	Compiuto l'intervento introducendo due nuovi comandi. Il primo notifica quali siano gli storages di un archivio all'applicazione così che essa possa decidere come operare, ovvero dove e come migrare gli allegati da uno storage ad uno differente. Il secondo comando provvede alla migrazione. Si veda la documentazione relativa.
	Rif.	eGreoupWare Activity #2142.
25/05 2011	xw	23.0.2.0	CE	Impossibile compiere attività sulle gerarchie di ACL.
	Nel nuovo B+Tree non sono state introdotte le funzionalità necessarie per la cancellazione delle chiavi, ciò rappresenta un limite ovvio alla funzionalità. Introdotta la funzione.
	Rif.	Attività di test della versione 23.
13/05 2011	xw	23.0.2.0 22.2.9.0 21.1.3.116_p32k12	CE	Applicazione xDocWayDoc. In presenza di un oggetto di ampie dimensioni l'ordinamento per numero di protocollo non viene compiuto correttamente ed il documento risulta il primo della selezione.
	Il problema è dovuto al fatto che la politica di costituzione dei titoli prevede che gli stessi siano autolimitati a 4Kb di dimensione massima, questo sia quando vengono richiesti in modalità normale sia quando vengono salvati nei files tit e tip. La regola di composizione del titolo può quindi far ricadere oltre la soglia dei 4Kb la parte da usare per l'ordinamento che, a quel punto, risulta non disponibile. Forzato il corretto reload Full Size in fase di ordinamento.
	Rif.	Cineca-Kion egW#1035.
10/05 2011	xw	23.0.2.0 22.2.7.0	CE	Mancata importazione documenti da WD in presenza di allegati. Si segnala un difetto di encoding che invece è corretto.
	Il problema è molto banale: la procedura che deve identificare nel documento quali elementi `xw:file` siano presenti e quindi quali allegati debbano essere importati fa il DOM del documento che però giunge senza la header che ne dichaira l'encoding. E' sufficiente aggiungerla d'ufficio, impostando l'encoding giusto, perché la procedura abbia il comportamento atteso. Fin quando si inviavano documenti in UTF-8 l'errore non veniva percepito.
	Rif.	Equitalia Nomos egW#1034.
13/04 2011	xw	23.0.2.0 22.2.7.0	CE	Perdita documenti nidificati in modifica del documento padre.
	Il problema si manifesta quando si presentano documenti nidificati. Modificando il documento padre i figli vengono mantenuti grazie alla mappa di sbiancamento che si trova nell'UDD del documento padre. Il documento è però già stato modificato e salvato e la vecchia componente UDD è stata liberata e sostituita. Soluzione temporanea: si evita di liberare la parte UDD vecchia, anche se andrà persa, in presenza di nidificazione, così che lo sbiancamento abbia luogo senza sovrascrivere i documenti figli.
	Rif.	Assistenza MAAS.
30/03 2011	xw	23.0.2.0 22.2.7.0	CE	Si verificano frequenti corruzioni degli indici.
	Il problema si riferisce alla presenza di chiavi con percorso relativi che possono presentare degli attributi non dichiarati. In tal caso si ha comportamento non corretto che porta alla produzione di due diversi set di chiavi, uno per gli attributi della prima presenza dell'elemento relativo nel percorso che lo contiene, e l'altra per ogni ulteriore presenza in percorsi “più interni” o diversi. Di fatto ci si confonde anche solo in indicizzazione di un semplice documento in quanto tra il primo rilevamento (indicizzazione differenziale positiva) ed il secondo (indicizzazione differenziale negativa) i due percorsi di chiave identificati per lo stesso percorso assoluto sono diversi. Ciò comporta una sporcatura negli indici.
	Rif.	eGWT#975 per Rcs Tribuna.
02/03 2011	xw	23.0.2.0 22.2.7.0	CE	Errore nei riferimenti a seguito modifica documenti.
	Il problema questa volta è dovuto all'estensione XSLT dei documenti. Se essa viene calcolata con successo ma ulteriori modifiche al documento comportano un risultato nullo, la componente precedentemente calcolata non veniva rimossa anche se in indicizzazione la nuova versione del documento ne risulta priva. Come effetto si ha che ad un successivo intervento modificante sul documento, l'indicizzazione differenziale trova nel documento vecchio una parte che de-indicizza ma per la quale le chiavi sono già state tutte rimosse e conseguentemente provoca un errore di indicizzazione.
	Rif.	eGWA#1535/]PO[2011/6, attività nell'ambito dei test sull'archivio TradeMark per Studio Ferrario.
02/03 2011	xw	23.0.2.0 22.2.7.0	CE	La funzione che deve tornare i contenuti XSLT di un set di documenti selezionati da esito errato.
	Banale errore dovuto all'uso degli indici nella selezione al posto dei numeri fisici dei documenti provenienti dalla selezione stessa.
	Rif.	eGWA#1535/]PO[2011/6, attività nell'ambito dei test sull'archivio TradeMark per Studio Ferrario.
25/02 2011	xw	23.0.2.0 22.2.7.0	CE	Errore nei riferimenti a seguito modifica documenti.
	Il problema era dovuto alla procedura che cerca di identificare la fine di una frase trovando un punto, uno o più separatori che potremmo definire innoqui ed un riporto a capo. In questo caso, se una precedente operazione aveva identificato un punto a fine riga, l'inizio del testo successivo che contenesse dei riporti a capo avrebbe provocato l'identificazione di una chiave di fine frase errata, collocata in un punto del tutto anomalo, che avrebbe quindi causato lo sfasamento di tutte le chiavi successive. Si denota, infatti, che un indice, su un allegato, composto con correttezza, all'atto della modifica dell'allegato stesso provocava la de-indicizzazione, prima di ogni altra chiave, della chiave di fine riga.
	Rif.	eGWA#1535/]PO[2011/6.
24/02 2011	xw	23.0.2.0 22.2.7.0 21.2.1.23	CE	L'indicizzazione di un archivio da crash e, se non li da, produce indici errati su campi multivalore.
	Il problema è dovuto al fatto che ci sono morsetti di indicizzazione che devono fare delle selezioni. Così facendo cambiano lo stato dei separatori²⁴⁾ e ciò ha un impatto diretto sull'indicizzazione di tutti i documenti successivi così come sulle successive parti del documento stesso. Salvato lo stato dei separatori prima della chiamata al morsetto in attesa di compiere un'intervento più corretto ed esaustivo.
	Rif.	eGW#940.
04/02 2011	xw	23.0.2.0 22.2.5.0	CE	Files temporanei sfruttati da procedure di lungo corso vengono rimossi anche se sono ancora in uso.
	Aggirato il problema provvedendo a rimoninare i temporanei candidati alla rimozione. Le funzioni che ne fanno uso verificano in assenza del temporaneo se esiste la versione rinominata e provvedono a riabilitarla.
	Rif.	eGW#933.
04/02 2011	xw	23.0.2.0 22.2.5.0	CE	L'impotazione di una chiave empty manda in loop l'indicizzazione di un documento.
	Problema dovuto ad un confronto case sensitive effettuato sull'XPath della chiave empty dovuto ad una mancata normalizzazione in sede di caricamento del file di configurazione d'archivio. Corretto il confronto perché non si basi sul case e corretto il caricamento perché normalizzi.
	Rif.	Prospect attività nomos.
02/02 2011	xw	23.0.2.0	CE	Errore indicizzazione archivio NSW.
	Nell'ambito di tale correzione, riveduto il meccanismo di chiamata della funzione morsetto durante l'indicizzazione.
	Rif.
18/01 2011	xw	23.0.2.0	CE	La ricerca per termine 'alnum' con wild card sembra operare senza di essa.
	La funzione di normalizzazione di quanto presente in un canale 'alnum' non teneva conto delle Wild Cards in ricerca e le eliminava come ogni altro carattere indesiderato. Corretto.
	Rif.	Prospect attività Studio Ferrario.
12/01 2011	xw	23.0.2.0	NF	Applicare l'estensione per genere e numero al singolo canale di ricerca.
	Dopo aver consentito di esprimere l'estensione per genere e numero direttamente in frase di ricerca apponendo al suo interno il modificatore globale [?MFSP] per consentire di applicare la stessa estensione ad un singolo campo è stato introdotto il modificatore di campo (Mfsp:1) che opera appunto solo sul campo cui si fa riferimento. La ricerca: `[marchio\|(Mfsp:1)]=calibro` identificherà quindi anche il termine `calibri`, `calibra` e `calibre` oltre a `calibro` e `calibr`.
	Rif.	Prospect attività Studio Ferrario.
23/12	xw	23.0.2.0	CE	La rilocazione dei documenti (al variare della file locatoin rule), ha un comportamento irregolare.
	La segnalazione espone alcuni comportamenti che, di fatto, sono tutti motivati da una ragione valida. Per risolvere comunque i principali inconvenienti si è fatto in modo che non si ricorra alla rilocazione di un documento se la sola ragione sarebbe l'allineamento alla DTD più recente se, di fatto, una simile DTD non viene chiamata in causa. Al contempo, la correzione di cui alla scheda eGW#919 risolve anche i problemi legati al compattamento che, di fatto, è piuttosto importante compiere subito dopo una rilocazione.
	Rif.	eGroupWare Ticket 789.
23/12	xw	23.0.2.0	CE	Il compattamento degli XML causa la perdita di documenti.
	Si tratta di un errore strutturale interno al server di vecchissima data che però non si manifestava sino a quando, col server 22, sono state abolite le iWords per i canali di ricerca che afferiscono al campo `UD`. L'errore, per altro, si manifesta solo se si richiede di compiere il compattamento degli XML senza tener conto delle incongruenze, vale a dire ignorando tutti i documenti che non risultassero presenti nella mappa. Serviva a pulire gli XML dagli “zombie” che in passato potevano sopravvivere ad alcune operazioni di modifica/cancellazione.
	Rif.	eGroupWare Ticket 919.
22/12	xw	23.0.2.0	NF	Esportare documenti indicanto gli allegati con percorso relativo.
	Esisteva già una funzionalità di esportazione che dichiarava di fare quanto detto ed invece agiva esclusivamente sulla denominazione che gli allegati avrebbero avuto nello .zip finale. Rettificato quindi il comportamento della suddetta funzionalità ed introdotto un nuovo flag di esportazione (`0x00400000`) che si occupa di convertire gli ID di allegati in percorsi relativi²⁵⁾.
	Rif.	eGroupWare Ticket 918.
15/12	xw	23.0.2.0	NF	Limitare l'estensione fonetica ai soli canali che la prevedono.
	Introdotto un modificatore specifico di canale che consenta di estendere solo ad esso l'estensione della ricerca fonetica. in pratica per ottenere la ricerca fonetica si può alzare il corrispondente bit nel comando ovvero… …porre nella frase di ricerca il modificatore `[?PHONO]` che si applica a tutti i canali indicati oppure… …apporre al singolo campo un modificatore specifico: `[testo\|(Phono:1)]=<valori>`. In quest'ultimo caso l'estensione fonetica si limita al canale in esame e non contamina le ricerche sugli altri canali.
	Rif.	Attività per prospect Studio Ferrario.
09/12	xw	23.0.2.0	CE	Capita ancora che inserimenti e modifiche non possano aver luogo a causa della presenza del file _.xml.
	Il problema si manifesta quando il file esiste ed al suo interno è presente esclusivamente la testata XML senza neppure un root element. La correzione prevede quindi che in tal caso il file venga rimosso e rigenerato ex-novo.
	Rif.	eGroupWare Ticket 878.
09/12	xw	23.0.2.0	CE	Il vocabolario di un archivio presenta dei termini che, pur affermando di selezionare più documenti, non ne selezionano affatto.
	L'errore è stato introdotto nel server da un intervento della versione 22.1.3.7 teso ad evitare di fare doppi indici per allegati con lo stesso contenuto. Si verificava se il testo che ci si accingeva ad indicizzare fosse corrispondente a quello dell'allegato appena indicizzato per non fare l'operazione due volte. Nel fare l'intervento non si era tenuto conto doverosamente del confronto tra vecchio e nuovo allegato che portava l'operazione a deindicizzare l'allegato del vecchio documento ma a non indicizzare mai quello del nuovo documneto se simili. In tal modo tutte le chiavi dell'allegato erano destinate a sparire. Nel momento in cui, in seguito, a causa di un intervento differenziale (modifica al contenuto dell'allegato ovvero sua cancellazione) si finiva con il togliere le chiavi dell'allegato esistente anche se esse non risultavano indicizzate in alcun modo. Ecco che si crea il caos. La funzione che deve fare l'intervento differenziale assume che se una parola in un documento ancora non c'era allora si tratta di inserimento, invece si trattava di cancellazione ed il risultato è appunto un record di una chiave che risulta esistente (punta ad un pezzo di ref che era quello precedente la sua cancellazione erronea), afferma di puntare ad uno o più documenti ma, malauguratamente, la catena di riferimenti è vuota, di 0 bytes, così come nullo è il numero delle occorrenze. L'intervento principale viene effettuato in indicizzazione degli allegati in modo che non si cancellino le chiavi quando in realtà il testo c'è eccome, così da non produrre l'errore più serio e grave quanto il documento viene del tutto rimosso. A dire il vero entrambe gli errori sono molto seri. In pratica o spariscono chiavi che invece sono presenti nei testi degli allegati oppure riappaiono pur non puntando più a quell'allegato.
	Rif.	eGroupWare Ticket 901.
07/12	xw	23.0.2.0	CE	La ricerca di alcuni termini che contengono caratteri stranieri provenienti dal vocabolari non da alcun esito.
	L'errore è dovuto ad un doppio problema. In primo luogo la codifica dei caratteri non appartenenti al set windows-1252 poteva avvenire con un encoding sia in forma decimale che esadecimale rendendo vana la ricerca. I test hanno inoltre evidenziato come la tabella di trasliterazione tra piattaforme diverse (Windows/Linux) fosse così differente²⁶⁾ da rendere gli archivi non compatibili in quanto gli indici calcolati su una piattaforma potevano risultare in 'disordine'²⁷⁾ sull'altra piattaforma azzerando la portabilità degli archivi. Si suggerisce comunque di compiere dei test sui vocabolari degli archivi, la dove presentino caratteri stranieri, quando si porta un archivio da una macchina ad un'altra ed alla bisogna rifare gli indici.
	Rif.	eGroupWare Ticket 909.
26/11	xw	23.0.2.0	CE	La costituzione degli indici di un archivio con allegati molto vasti produce indici già corrotti.
	L'errore va ricercato nel trattamendo dei Buddy Files nei quali non è prevista alcuna area di dimensioni superiori ai 64MB. L'archivio sul quale il problema si manifesta ha aree più vaste ed in assenza degli opportuni controlli si rischiava di trabordare dalla lista dei liberati del file .ref, accedere alla prima area contenuta nel file scamiandola per un'area liberata e corrompere, di conseguenza quell'indice. La mancanza di una verifica sul limite in essere causava un potenziale calcolo dello spazio richiesto per una catena di riferimenti errato (si pescava in un area di memoria non inizializzata) e poteva condurre anche ad un Crash del server. Ampliata la portata del server, ora in grado di gestire catene di riferimenti ipoteticamente sino ai 2GB. Nei Buddy Files la dimensione massima gestita dall'area dei liberati rimane di 64MB ma possono essere create aree di dimensioni superiori le quali, però, sfuggono alla gestione delle aree liberate e se non utilizzate divengono spazio perso non recuperabile a meno che non si compia un compattamento degli indici. In seguito si provvederà a liberare una serie di aree di varie dimensioni così da non sprecare irrimediabilmente lo spazio disponibile.
	Rif.	eGroupWare Ticket 904.
22/11	xw	23.0.2.0	CE	Acquisendo una serie di files XML tramite WatchDoc si causa un danneggiamento degli indici.
	L'errore è stato introdotto nella gestione del documento in indicizzaizione propria del server di classe 23, non affligge quindi le versioni precedenti In un ciclo generato da WatchDoc si trattano diversi documenti. Nel nostro caso il problema si ha quando un nuovo inserimento segue un'aggiornamento di un documento esistente, rilevato grazie alla sua regola di univocità. In quel caso si aveva come permanenza, come strascico, la presenza del documento vecchio precedente mentre si procede all'inserimento del documento nuovo. La funzione di indicizzazione sa che dev'essere un inserimento ma riceve un OldDoc e causa un errore che si riflette sugli indici. Corretta questa modalità in modo che al termine di ogni ciclo non si lasci traccia del vecchio documento modificato così da non soffrirne in seguito. Il problema, di fatto, non si manifestava ne in caso di tutti aggiornamenti ne in caso di tutti inserimenti. La correzione rende deprecata la versione precedente di server.
	Rif.	eGroupWare Ticket 903.
08/11	xw	23.0.2.0	CE	L'indicizzazione degli ID degli allegati alle volte fallisce.
	L'errore va ricercato in un difetto di normalizzazione dei percorsi XML particolarmente nidificati quali sono, ad esempio, quelli degli allegati di cui si è fatta ampia nidificazione. In tal caso, nel determinare il tipo di indice da compiere sul campo, si può avere un troncamento erroneo del percorso cui fare riferimento. Questo conduce all'errore in esame che inficia tutti gli indici del documento corrente. Va inoltre rilevato che, nonostante l'errore di indicizzazione, la condizione d'errore viene “appiattita” ed il comando torna in modo positivo nonostante tutto. Ciò è piuttosto grave. Nota: La correzione viene apportata anche alle candidate 22.1.3.12 ed ai sorgenti Kion che manifestano lo stesso difetto.
	Rif.	eGroupWare Ticket 893.
28/10	xw	23.0.2.0	CE	L'indicizzazione degli ID degli allegati non consente l'indicizzazione di chiave nulla.
	L'errore è dovuto al fatto che con la versione 21.2.0.* si è introdotto un controllo che inibisce la configuarzione del campo //xw:file/@name nel file <nomearchivio>.conf.xml pur forzando l'indicizzazione del valore nullo per tal campo. Nonostante quest'intervento, non ponendo tra le chiavi configurate anche la chiave //xw:file/@file, non si componeva correttamente la sequenza delle chiavi empty e quindi tale chiave non veniva prodotta. Intervenuti modificando la funzione che compone tale stringa in modo che forzi tale canale di ricerca come canale empty indipendentemente dalla configurazione, che anzi è tutt'ora sconsigliata in quanto inutile e traviante.
	Rif.	eGroupWare Ticket 884.
26/10	xw	23.0.2.0	CE	Errore nell'assegnazione dei valori seriali.
	Se si assegna un valore seriale dopo aver provocato un errore di univocità si corre il rischio di avere un'erronea assegnazione con un salto di numerazione. L'errore è molto grave e serio.
	Rif.	eGroupWare Ticket 716.

23.0.1.0

N.B.: Questa versione presenta un side effect qualora si faccia uso di WatchDoc. Per un simile utilizzo si consideri questa versione deprecata.

Introduzione del concetto di profilo. Abolizione del file xusers.xml a favore di un diverso sistema di autenticazione ed adozione di profilo di sistema e d'archivio.
Modalità Blind, con .conf.xml minimale.
Impostazioni di indicizzazione direttamente nel campo che viene sottoposto al server.
Revisione generale delle politiche di locking/flushing ed uso della cache del BTree in molteplici casi.
Adozione del B+Tree in tutti i punti possibili, sia nelle attività che riguardano il file system sia per le operazioni di indicizzazione in memoria.

Data	Mod	Ver		Sintomo o Segnalazione
28/09	xw	23.0.0.1_hot_wip “EVO” 22.1.3.11	CE	Impossibile reperire un allegato.
	il problema era già stato affrontato nel settembre 2009 con scheda eGW#38 ma la soluzione, non verificata in modo completo, manteneva alcune condizioni d'errore. Apportata ulteriore correzione. Vds eGW#863.
28/09	xw	23.0.0.1_hot_wip “EVO” 22.1.3.11	NC	Applicazione UAC²⁸⁾.
16/09	xw	23.0.0.1_hot_wip “EVO” 22.1.3.10	NC	Search & Replace incapace di compiere un'attività precisa.
	Le procedure di Search & Replace risultano incapaci di compiere un'attività più precisa e capillare. Nella fattispecie è incapace di saltare i documenti in cui la modifica richiesta non abbia senso e non venga applicata ne di indicare, nei casi di errore, quali documenti siano interessati dagli errori ed in che modo Implementato con l'aiuto di Gregorio un nuovo procedimento in grado di identificare le attività positive da quelle non effettuate e regolarsi di conseguenza. Dettagli nella documentazione del comando.
10/09	xw	23.0.0.1_hot_wip “EVO” 22.1.3.9	CE	Crash del server in accesso al vocabolario.
	A quanto è possibile vedere, il buffer globale destinato al trattamento delle chiavi era sottodimensionato rispetto alla massima dimensione lecita per una chiave. Se pure è raro che essa si presenti negli indici dei documenti, è invece facile che si manifesti nel thesaurus che prevede chiavi molto lunghe e composte da due parti entrambe ampie. Vds. GWT000855.
03/09	xw	23.0.0.1_hot_wip “EVO” 22.1.3.9	CE	L'esecuzione di un Search & Replace da esiti errati.
	Pur eseguendo correttamente il proprio compito, l'attività di Search & Replace indicava erroneamente quante e quali fossero i salvataggi effettuati e con quale esito..
09/08	xw	23.0.0.0_hot_wip “EVO”	CA	Emissione Candidate da testare internamente
02/08	xw	23.0.0.0_hot_wip “EVO” 22.1.3.7	CE	L'import da WatchDoc di documenti con encoding non corrispondente a quello dichiarato nel file presenta una condizione d'apparente correttezza ma lascia il file `.fail` sul proprio percorso.
	L'intervento effettuato nella precedente 22.1.3.6 non azzerava il codice d'errore vanificando quindi l'operazione di salvataggio.
30/07	xw	23.0.0.0_hot_wip “EVO” 22.1.3.7	CE	La costituzione del catalogo che preveda l'applicazione di un foglio di stile XSLT alle volte, pur non dando errore, non produce alcun risultato.
	Il difetto va ricercato nel fatto che la funzione riceve puntatore e dimensione del buffer da elaborare ma se vi deve applicare anche il namespace `xw:` per poter interpretare correttamente gli allegati, compone mane il buffer da elaborare perché ignora la size notificata. In inserimento e modifica la cosa non si avverte ma nel fare catalogo da file (quindi anche da WatchDoc) l'errore può presentarsi. Rettificato l'uso della dimensione anche in quel punto e corretto l'errore.
27/07	xw	23.0.0.0_hot_wip “EVO” 22.1.3.7	CE	La combinazione di ranges in forma di “Or List” ed altre estensioni (genere e numero, thesaurus, somiglianza, fonetica, etc.) non da l'esito atteso. Le estensioni non risultano applicate.
	L'errore è dovuto al fatto che il range in forma di “Or List” veniva trattato come tutti i ranges, ovvero estraendo esattamente quei termini dal vocabolario, senza tenere in considerazione la possibilità che da essi si derivassero altri termini. Tutte le altre forme di range si avvalgono espressamente ed intenzionalmente dei termini presenti nel vocabolario, e solo di essi, ma questo range fa naturalmente razza a se. Vds. eGW#000840.
21/07	xw	23.0.0.0_hot_wip “EVO” 22.1.3.7	CE	La presenza di parentesi quadre nella frase di ricerca che non intendano racchiudere un campo conduce a comportamenti inesatti/inattesi. La forma [campo1]=[campo2] non da errore ma non da esito..
	La richiesta (Vds. eGW#000770) non può essere accolta in quanto un tentativo di abbattere l'ambiguità data dall'uso improprio di parentesi quadre al fine di considerarle alla stregua di una strina qualsiasi impatta con la ricerca con Anyalias e la ricerca multi archivio, oltre a confliggere con alcuni casi di univocità. La correzione si limita ad inibire e considerare sintatticamente errata la forma [campo1]=[campo2].
19/07	xw	23.0.0.0_hot_wip “EVO” 22.1.3.7	CE	Le ricerche per numero documento confliggono con le estensioni, ad esempio, per genere e numero.
	Difetto riscontrato e corretto. Vds eGW#000836.
19/07	xw	23.0.0.0_hot_wip “EVO” 22.1.3.7	CE	Gli indici corrotti dilagano a macchia d'olio e bloccano il funzionamento dell'archivio.
	La problematica era già stata trattata in precedenza, per interrompere l'uso della catena dei liberati di un Buddy File quando essa risultasse corrotta. La correzione era però insufficiente in quanto utilizzava comunque una prima area già riutilizzata con riflessi molto pericolosi sulla consistenza di quell'indice. L'attuale correzione (Vds. eGW#827) è pensata per evitare anche questo problema.
14/07	xw	23.0.0.0_hot_wip “EVO”	NC	Nel visualizzatore eventi appaiono una serie di segnali che risultano errori pur non essendo nulla di serio e creano un ingiustificato allarme.
	Compiute due verifiche. In primo luogo non vengono più registrate come errori i mancati logs che si cerca di inviare a xwls prima ancora che l'interfaccia per fare logging sia stata del tutto avviata. In secondo luogo, tutte le informazioni inviate al Log Giornale vengono riversate anche sul log di sistema ²⁹⁾ quindi si evita di indicare come Warning segnalazioni fisiologiche o innocenti. (Vds. segnalazione eGW000744).
13/07	xw	23.0.0.0_hot_wip “EVO” 22.1.3.7	NC	Evitare gli indici degli allegati quando essi si presentino di identico contenuto.
	La funzionalità è stata concepita e sviluppata per avvantaggiarsi in scenari in cui ci siano allegati identici (Vds. segnalazione eGW000735) cosa che avviene non di rado ad esempio quando si allegano più versioni di un determinato documento in cui il testo non risulti di fatto cambiato. Malauguratamente, per la suddetta segnalazione, questo intervento risulta inutile.
12/07	xw	23.0.0.0_hot_wip “EVO” 22.1.3.7	CE	Le attività massive che interessano conversioni XSLT sono estremamente lente.
	Tentata un'ottimizzazione mantenendo caricato ed utilizzabile l'ultimo foglio di stile XSLT utilizzato al fine di evitare un inutile overhead nel ricaricare continuamente un oggetto sempre identico. Purtroppo il guadagno in termini prestazionali non è ancora sensibile come speravamo, perché limitato all'XSLT e non ha effetti sul tempo necessario al caricamento DOM del XML da elaborare.
01/07	xw	23.0.0.0_hot_wip “EVO” 22.1.3.6	CE	Gli errori di encoding rendono inusabili le vecchie applicazioni.
	Il server non deve accettare che documenti dichiarati in encoding `iso8859-1` contengano, in realtà, caratteri appartenenti all'enciding `windows-1252`. La modifica di recente introduzione che inibisce il salvataggio di simili documenti, pur essendo corretta, causa diversi problemi alle applicazioni esistenti. Per ovviare a questo si può introdurre, nei vecchi archivi, una voce di profilo che rende più lasco il controllo. Il server si limiterà ad indicare che c'è un errore di encoding senza provocare un errore bloccante. <profile type="arc.test_encoding" value="false"/>
01/07	xw	23.0.0.0_hot_wip “EVO” 22.1.3.6	CE	Esprimendo un range di valori sotto forma di or list, il programma ha un comportamento strano se uno di tali valori è il valor vuoto.
	Ci sono due ordini di problemi. Se il valor vuoto viene espresso con la sequenza &null; la presenza del punto e virgola confonde l'interprete dei ranges in quanto anch'esso è uno dei separatori di range. Se il valor vuoto viene spresso con "&null;" il comportamento è corretto mentre se si indica semplicemente "" l'esito non comprende il valor vuoto. Sul primo problema c'è poco da fare, la sintassi rischia la confusione quindi si deve fare attenzione nell'utilizzo, il caso della sequenza ”“ è stata equiparata a quella del termine ”&null;“. Ammessa come valida anche la forma [campo]={valore} ovvero [campo]={"valore"} che viene trattata come or list anche se l'elenco è composto da un solo valore. Vds eGroupWare #820.
29/06	xw	23.0.0.0_hot_wip “EVO” 22.1.3.5	CE	La ricostruzione integrale di un archivio, in presenza di difetti che ne comportino la rimozione del file .stat.xml, causa la perdita dei seriali.
	Il server assume che se un archivio esiste i suoi seriali si conservano, se non esiste si butta ogni cosa si trovi lungo la strada, assumendo che siano dati errati. Per sapere se l'archivio esiste ci si basa sul file nomearchivio.stat.xml in assenza del quale si assume che ci sia di buono solo il .conf.xml. In questo caso si perde il .ser.xml in quelle occasioni in cui sia stato necessario cancellare alcuni file dell'archivio perché danneggiati o incompatibili con la versione di server che si va ad usare. Visto che il flag di salvaguardia dei seriali esiste dalla notte dei tempi ma mai nessun client ne ha fatto uso, il server ora agisce d'ufficio salvaguardando sempre i seriali ed i thesaurus ed ignorando l'eventuale flag ricevuto. IL server 23 mantiene però la possibilità di gestire la rimozione dei seriali in caso di comando di “drop” d'archivio per gli archivi Lucene, ovvero gli archivi “blind”. Vds eGroupWare #788.
29/06	xw	23.0.0.0_hot_wip “EVO” 22.1.3.5	CE	Titoly lazy di più archivi si rubano continuamente la scena, rendendo molto più lento del necessario il compito di ricostruzione lazy dei titoli.
	Il problema dipende dal fatto che mente si sta facendo un'operazione di lungo corso, come ad esempio il rifacimento dei titoli, il server tenta di fare anche altre attività eventualmente prioritarie. Per tale ragione da un po' di tempo a ciascuno dei compiti collocati nella directory `lazy` contando che, chi più chi meno, arriveranno tutti a termine senza particolare ritardo. Dalla versione corrente del server i compiti lazy sono stati razionalizzati e quindi è stata data priorità 'A' alle indicizzazioni off-line, priorità 'B' alle indicizzazioni delle modifiche dei documenti e priorità 'Z' ai titoli. In questo modo, mente si stanno facendo i titoli di un archivio, altri titoli non distoglieranno il primo dal suo compito mente attività a priorità superiore verranno svolte comunque prima interrompendo il flusso di attività in corso. Inoltre da adesso i titoli off-line vengono sempre fatti lazy, salvo divesa disposizione del chiamante. Vds eGroupWare #796.
09/06	xw	23.0.0.0_hot_wip “EVO” 22.1.3.4	CE	L'idicizzazione dell'archivio docway di Asolo da crash del server.
	Il problema è dovuto al fatto che si indicizza in un certo “lotto” una chiave che appare due volte. Ciò significa che è stata inserita due volte nel BTree in memoria considerandole distinte ma che risulta la stessa chiave nel BTree su disco. Questo comporta che la chiave venga scaricata due volte producendo un file .LOT inconsistente (non può essere scandito in modo corretto) che provoca un crash in fase di scarico finale. Corretto l'errore intervenendo sulla funzione di normalizzazione delle chiavi.
28/05	xw	23.0.0.0_hot_wip “EVO” 22.1.3.4	NF	Semplificare la procedura per la realizzazione di archivi per CD.
	Realizzato un singolo comando in grado di compiere tutti i passi necessari alla realizzazione di un archivio che sia il clone integrale o semplicemente di una parte di un altro archivio. L'archivio così ottenuto può essere già pronto per l'uso su un supporto ottico e con una distribuzione di server in grado agire su archivi così protetti.
26/05	xw	23.0.0.0_hot_wip “EVO” 22.1.3.4	CE	Non si riesce a compiere un'importazione via WatchDoc su alcuni archivi.
	Se un archivio privo di file_location rule la modalità usata dal server per identificare in quale file XML scrivere il documento è quella detta single³⁰⁾. La procedura che determina il nome di tale file è la stessa usata per gli allegati. In tale frangente, essendo fondamentale l'univocità, un archivio non completamente indicizzato causa errore. Questo è lo scenario che si presenta dopo l'importazione del primo documento via WatchDoc. Allentata la stretta del controllo sull'univocità quando la procedura viene utilizzata per scopi legati ai files XML anziché agli allegati.
10/03	xw	23.0.0.0_hot_wip “EVO”	CE	L'indicizzazione di alcuni allegati manda in crash il server.
	Il problema va ricercato nel fatto che l'adozione dell'OCR Tesseract produce alle volte documenti contenenti una grande quantità di dati errati il cui formato, di fatto, è UTF-8 anche se il file è del tutto testuale. Dal server di classe 22 si introduce un test che fa sì che si proceda alla conversione del contenuto secondo il detto encoding così da compiere un'indicizzazione dei contenuti il più corretto possibile. Malauguratamente quest'attività può condurre ad una crescita anche sensibile della stringa che rappresenta il contenuto dell'allegato in quanto da UTF-8 a WinLatin1³¹⁾ molti caratteri possono risultare non traducibili e vengono quindi traslati in entity numeriche. La funzione a ciò preposta allocava un po' di spazio in più senza valutare correttamente il dafarsi. Nel server 22 si è provveduto a compiere un'allocazione di memoria più vasta, nel 23 si passa all'uso di `std::string` così da aggirare completamente l'ostacolo. Vds eGroupWare #750.
04/03	xw	23.0.0.0_hot_wip “EVO”	CE	A seguito di un'azzeramento d'archivio il risultato dello stesso è inutilizzabile.
	Mancando una reale condizione di test sulla concorrenza tra l'azzeramento di un archivio, considerato abbastanza definitivo per non dover prendere particolari precauzioni, ed eventuali operazioni di inserimento e modifica, è possibile, in linea teorica (ed anche in linea pratica a giudicare dalla segnalazione eGW #747) che un server sovrascriva il file nomearchivio.stat.xml e le header degli altri files dopo che un altro server ha provveduto all'azzeramento. L'archivio risultante se tutto va bene, non può più essere aperto³²⁾ ne quindi si riesce a ricostruirlo da capo se non rimuovendo a mano i files. Si da il caso, però, che il server che l'ha azzerato, convinto della sua validità sulla base di quello che ha in cache, consente operazioni come la costituzione della mappa e dei titoli con risultati drammatici³³⁾. Compiuto un intervento che si assicura di bloccare l'archivio esistente prima di rimuoverlo così da assicurarsi che l'archivio risultante sia corretto.
04/03	xw	23.0.0.0_hot_wip “EVO”	CE	L'accesso al vocabolario con pattern causa condizioni di loop.
	La verifica della presenza di un pattern comune in caso di ricerca delal chiave greater non teneva conto correttamente, nelle successive letture 'next', che la radice fosse per lo meno comune. Vds. GWT000639
04/03	xw	23.0.0.0_hot_wip “EVO”	CE	In fase di spegnimento servizi capita che un server slave rimanga attivo e consumi CPU.
	L'errore si ha quando un server slave riceve il comando che lo informa che deve chiudersi. Tale comando, asincrono, viene gestito da un apposito handler il quale è pensato per essere eseguito in modo recursivo ogni volta che esso rileva che c'è un comando ancora pendente. Il bit del comando di chiusura non viene abbattuto in quanto è utile sapere che la chiusura è stata richiesta. Inibita la reiterazione qualora il solo comando pendente sia quello di chiusura. Vds. GWT000559
04/03	xw	23.0.0.0_hot_wip “EVO”	CE	L'esecuzione massiva della ricostruzione titoli produce un file di titoli inutilizzabile e quindi causa sensibili rallentamenti a tutto il sistema.
	Il problema s'è manifestato da quando, nella costituzione dei titoli, si è deciso di procedere dall'ultimo al primo³⁴⁾ anziché in ordine numerico naturale. La procedura che provvedeva a sbiancare la parte di file .tip non ancora valorizzata compiva un errore banale sovrascrivendo anche la header con risultati disastrosi. Vds. GWT000636
03/03	xw	23.0.0.0_hot_wip “EVO”	CE	L'applicazione di un filtro nell'accesso al vocabolario che presenti un asterisco come primo carattere produce una stringa vuota.
	Il confronto sul pattern era corretto ma, malauguratamente, tale confronto non doveva limitarsi ad affermare se la stinga fosse corrispondente o meno, ma anche se si fosse ancora in un range utile per evitare che il controllo sul pattern scandisca inutilmente tutto il vocabolario. Per verificare se si rientra nel range si controlla la corrispondenza della parte radice della chiave che in presenza di Wild Card come primo carattere non dava un risultato significativo. In questo caso, ora, si asserisce di essere sempre nel range.
19/02	xw	23.0.0.0_hot_wip “EVO”	CE	Indici corrotti.
	Problema dipendente dalla presenza di un carattere 'þ' che veniva maldestramente interpretato dalla funzione di normalizzazione. Il problema è stato arginato mettendo una vera e propria pezza nelle funzioni che inseriscono le chiavi nel BTree/CBtree/BTreeMem ed imponendo un ulteriore filtro nella funzione di indicizzazione incrementale o differenziale che inserisce le chiavi visto che in alcuni casi, meno rari del previsto, si inseriva una chiave vuota. Vds GWT000596.
28/01	xw	23.0.0.0_hot_wip “EVO”	CE	Le attività di log impattano sulle performance più di quanto si attenda.
	Cambiata la politica di logging usando un thread parallelo lockless che compie il logging mentre il thread principale procede nelle sue attività. Se lo sviluppo si dimostrerà efficace a simili threads verrà dato il compito di fare altre operazioni, come la registrazione delle attività lazy o del registro..
27/01	xw	23.0.0.0_hot_wip “EVO”	CE	Caccia alle performance.
	Cambiata la politica di apertura degli archivi per riconoscere i comandi Archiveless senza dispendio di tempo. Abolite inutili memset di aree di memoria quando non necessario. Ridotta l'allocazione di memoria che viene fatta per fare cache della selezione in corso di esecuzione che era eccessiva e spostata sullo stack.
22/01	xw	23.0.0.0_hot_wip “EVO”	CE	In assenza del file context.stat.xml esso viene creato alla prima registrazione ma viene realizzato errato.
	Corretta la stesura del file nel quale, se assente, un attributo id veniva realizzato erroneamente come elemento.
30/12	xw	23.0.0.0_hot_wip	CE	Compiere BenchMark non fornisce facilmente indicazioni statistiche utili.
	Introdotta una modalità di stesura di un log di BenchMark che semplifica la vita al tester. Vds GWA001344.
29/12	xw	23.0.0.0_hot_wip	CE	Nel compiere dei BenchMark con altre versioni del server verificata una lentezza in modifica documenti.
	Il problema è stato arginato adottando l'uso della cache del BTree anche in modifica, cosa che non era mai stata fatta. Vds GWA001344.
24/12	xw	23.0.0.0_hot_wip	NF	Nel compiere dei BenchMark con altre versioni del server nota che viene compiuto un numero irragionevole di letture, seek, scritture e flush dei files dell'archivio.
	La gestione delle letture delle header, delle loro scritture e dei flush degli archivi era sparsa un po' ovunque e costringeva a rileggere continuamente per esser certi di avere a disposizione una versione affidabile. L'intera gestione degli accessi alle headere è stata riveduta e migrata, per competenza, al più basso livello disponibile, ovvero al livello del singolo file. Ora, quando si blocca un archivio e si provvede al caricamento delle header dei files, gli stessi vengono etichettati in modo da evitare ogni ulteriore reload delle header non necessario. In questo modo viene riveduto anche tutto il comportamento delle librerie dinamiche tornando ad avere un comportamento finalmente coerente. La verifica sul campo dimostra che il numero di letture e scritture è sensibilmente diminuito con evidenti benefici.
17/12	xw	23.0.0.0_hot_wip	NF	Nello sviluppo della sintassi per Lucene ci sono alcune forme di range non previste.
	I range mancanti sono quelli che potremmo definire misti. ExtraWay server prevede sia i ranges inclusivi che esclusivi, ovvero i ranges nei quali gli estremi indicati debbano appartenere o meno all'esito finale della selezione. Lucene prevede, oltre ad essi, i ragnes che risultano inclusivi solo per uno dei due estremi. Per integrare questo comportamento sono stati aggiunti i modificatori dei ranges '>' e '<' che si aggiungono a quelli già indicati L'espressione: [campo]={minval>maxval} Indica che il range richiesto dovrà comprendere l'estremo espresso con minval ed escludere l'estremo espresso con maxval Analogamente l'espressione: [campo]={minval<maxval} Indica che il range richiesto dovrà escludere l'estremo espresso con minval ed includere l'estremo espresso con maxval.
03/12	xw	23.0.0.0_hot_wip 21.2.1.20	CE	I timestamp interni, senza il carattere 'T' del formato ISO, non vengono trattati adeguatamente.
	Esteso il trattamento delle chiavi che rappresentano un timestamp³⁵⁾ anche in assenza del separatore 'T' che ne qualifica la forma riconosciuta ISO.
30/11	xw	23.0.0.0_hot_wip	NF	Le selezioni in modalità `Lucene` richiedono che il grado di somiglianza sia configurabile per singola ricerca.
	eXtraWay Server prevedeva esclusivamente l'indicazione della ricerca per somiglianza dei termini applicata all'intera selezione. Dalla versione in esame è stata introdotta la possibilità di indicare invece una somiglianza per singolo termine o, più precisamente, per il singolo campo sul quale si sta compiendo la selezione stessa. Vedasi la documentazione relativa.
26/11	xw	23.0.0.0_hot_wip	NF	Per compiere diverse tipologie di selezione, tra le quali quelle in stile Lucene, sono state implementate le operazioni di ricerca in cascata.
	Vedasi la documentazione relativa.
25/11	xw	23.0.0.0_hot_wip	NF	Per realizzare archivi da utilizzarsi nello scenario Lucene si devono costituire archivio con caratteristiche particolari.
	Introdotto il concetto di Archivio “Blind” che ciecamente accetta documenti ed alias di ricerca anche in assenza di una specifica configurazione. Vedasi la documentazione relativa.
12/11	xw	23.0.0.0_hot_wip	NF	Il compattamento archivio viene fatto anche se inutile.
	Con l'adozione del B+Tree cambia completamente la filosofia del compattamento. Il compattamento del file `.idx.bpt` può risultare molto utile (la procedura che lo genera lo riempie lasciando molto sfrido) e viene eseguita a parte rispetto al resto. Il compattamento di VCB e REF viene ora effettuato solo se nel Ref c'è uno spazio libero superiore ai 256Mb o in generale se lo spazio libero supera il 10% dello spazio totale del file REF. Questo in particolar modo perché a seguito di indicizzazione Off-Line il ref è praticamente già compattato. L'unica caratteristica che manca ai 3 files è quella di essere in ordine (l'ordine dei record del VCB corrispondente all'ordine delle chiavi nel B+Tree e conseguentemente corrispondente all'ordine dei blocchi del REF) cosa che aiuterebbe in accesso sequenziale (ricerche per range, accesso ai vocabolari e simili) ed eventualmente per le applicazioni distribuite su supporto ottico.
11/11	xw	23.0.0.0_hot_wip	NF	Dover affrontare archivi di dimensioni sempre maggiori impone prestazioni più imponenti.
	Compiuti considerevoli interventi nell'indicizzazione Off-Line che portano archivi di dimensioni considerevoli ad essere indicizzati in tempi molto più rapidi. _{Per portare un esempio, l'indicizzazione dell'archivio Agi che richiede, per una versione 22.1.2.0 un tempo di 8h07' viene compiuta dalla versione attuale in 4h59'. Un archivio campione di Regione Veneto è passato da 13h05' a 9h22'³⁶⁾}. Il programma fa attualmente un uso maggiore della Ram, utilizzando quindi una cache più spinta. A tale scopo è stato modificato il file di configurazione³⁷⁾ nella sezione `[hs]` aggiungendo una nuova voce `CacheSize` il cui valore identificato come segue:
	`CacheSize` presente e diverso da '0'		Rappresenta il numero di Mb da usare per la Cache. Ora si utilizzano due distinte forme di Cache quindi metà dello spazio indicato verrà usata per la Cache del B+Tree e l'altra metà per la lavorazione delle catene dei riferimenti. I valori di `NodiCacheMax` e `KRAM` vengono ignorati.
	`CacheSize` assente o uguale a '0'		Il valore della Cache viene ottenuto prendendo in considerazione il valore di `NodiCacheMax`³⁸⁾ e `KRAM`³⁹⁾. Entrambe i valori vengono tradotti in Mb e `CacheSize` assume il doppio⁴⁰⁾ del massimo dei due valori.
	Vengono inoltre aboliti i seguenti valori di configurazione⁴¹⁾: `AreaDiLavoro`, `AreaDiLavoroMax`, `FiltroInizio` e `FiltroFine` mentre, come già detto, i valori di `NodiCacheMax` e `KRAM` vengono presi in esame solo in assenza di `CacheSize`. Il valore di `NodiCache` cambia il proprio valore di default da `510` a `1020`. _{Nota: Si consideri che con server sino alla classe '22' una configurazione tipo poteva prevedere un valore di NodiCacheMax pari a 192000 e di KRAM pari ad 80000. In questo scenario si finiscono con l'utilizzare 96Mb di Ram per la Cache del BTree e poco meno di 80Mb per il trattamento dei lotti. Questi due ammontare di memoria venivano allocati e liberati in momenti diversi quindi l'occupazione effettiva massima corrispondeva a 96Mb. Dal server 23 si sfrutta, in ognuna delle due fasi dell'indicizzazione Off-Line il doppo della Ram il che comporta un utilizzo medio di 192Mb di Ram. Le impostazioni suddette equivalgono quindi ad indicare esclusivamente CacheSize=192.}
30/10	xw	23.0.0.0_hot_wip	NF	La gestione di un archivio richiede, anzi impone in alcuni casi, che per ottenere i risultati voluti in termini di indicizzazione sia necessario modificare il file di configurazione d'archivio per introdurre nuovi tipi di canali.
	Introdotto il concetto di canali autodefiniti. Rimane sempre vero quanto detto per attributi ed elementi che vengono indicizzati reciprocamente come monovalore e multivalore, alfanumerici e con l'applicazione della StopList⁴²⁾ solo per gli elementi. Se un elemento⁴³⁾ è corredato da alcuni attributi appartenenti al namespace `xw:`, essi vengono interpretati come modificatori dell'espressione della chiave e producono una chiave che ha particolari caratteristiche, eventualmente distinte dalle condizioni di default. Sono ammessi alcuni valori noti che derivano diretattamente da quelli già esistenti nel file di configurazione d'archivio ed altri di nuova concezione.
	Attributo		Valori Ammessi (in Verde i valori di default, in Grigio i valori supportati ma di più raro utilizzo)
	xw:key_style		single, one, multi, double, skip, one-md5, one-md5cs, double-md5, double-md5cs, spatial.
	xw:value_type		date, num, alfa, file, alnum.
	xw:instance		Qualsiasi valore positivo o negativo (es.: true, yes, on, 1 ovvero false, no, off, 0)
	xw:store		Qualsiasi valore positivo o negativo (es.: true, yes, on, 1 ovvero false, no, off, 0). Indica se si richiede o meno la conservazione del dato dopo aver provveduto a farne gli indici. All'atto della stesura della presente documentazione, quest'opzione viene prevista ma non implementata: il server farà comunque storage del dato.
	xw:analyzer		Identificatore univoco dell'analizzatore del testo da applicare sul contenuto del canale. All'atto della stesura della presente documentazione, quest'opzione viene prevista ma non implementata: il server applicherà comunque l'analizzatore/tokenizzatore di default.
21/10	xw	23.0.0.0_hot_wip	CE	Il test di Wellformedness dei documenti può essere inibito con conseguenze anche gravi sui contenuti degli archivi.
	Ignorata l'inibizione introdotta in versioni molto vecchie. Ora il test avviene sempre e comunque nelle fasi di salvataggio di singoli documenti come di serie di documenti⁴⁴⁾. Rimane la possibilità di inibire il test in fase di catalogo, assumendo che tutti gli XML dell'archivio, inseriti compiendo il test, siano intrinsecamente validi.
03/08	xw	23.0.0.0_hot_wip	NF	Le modifiche registrate ne file di registro mostrano il documento com'era e non com'è. Dei documenti meramente inseriti, in sostanza, non v'è traccia alcuna.
	Si deve compiere un'attività più precisa, registrando i documenti inseriti e, dove presenti, sia l'originale che la modifica se pure con una crescita del registro potenzialmente sensibile.
??/08	xw	23.0.0.0_hot_wip	NF	Rifacendo il catalogo di un archivio, le date di inserimento e modifica degli stessi evidenziate nella risposta al caricamento ovvero disponibili sotto forma di vocabolari subiscono una trasformazione ed appiattimento.
	Il vocabolario delle date di inserimento e modifica dei documenti viene ora prodotto sulla base delle processing instruction presenti nei documenti stessi divenendo indipendente dalla ricostruzione del catalogo.

Versioni precedenti

La documentazione inerente le versioni precedenti è reperibile alla pagina Procedure di Test piattaforma eXtraWay (Vecchie Versioni) - Documentazione Riservata

¹⁾

Venivano presi in esame solo xw:file e ?xw-file

²⁾

Cartella di Share

³⁾

Le chiavi th_link nella sezione thesaurus del <nomearchivio>.conf.xml.

⁴⁾

MEMBUFF

⁵⁾

.tar.gz o .pdf.p7m ad esempio

⁶⁾

Analisi spettrale

⁷⁾

Che possono essere prodotti da termini che precedono, seguono o che sono nel mezzo dell'espressione o anche da un'espressione con stessi termini in altro ordine

⁸⁾

In cancellazione non viene ovviamente fornito al server alcun documento

⁹⁾

In precedenza solo il codice I veniva scartato se la configurazione non prevedeva il livello più basso di logging

¹⁰⁾

relativo

¹¹⁾

non l'elemento padre ma un qualche elemento di livello superiore

¹²⁾

In Unicode questi caratteri, vale a dire quelli compresi tra 0x80 e 0x9f, sono codici di controllo e non corrispondono a caratteri “stampabili”.

¹³⁾

Che per altro sono considerati separatori e quindi non causano effettivi difetti

¹⁴⁾

Pratica ormai caduta in disuso

¹⁵⁾

Si intende l'ordine in cui i documenti sono stati inseriti nell'archivio ovvero l'ordine in cui il server li ha identificati facendo la mappa da file XML esistenti

¹⁶⁾

Ovvero windows-1252, il formato adottato per esprimere le chiavi del vocabolario

¹⁷⁾

SrcStp:null

¹⁸⁾

Pratica comunque deprecabile cui ricorrere solo in caso di estrema necessità

¹⁹⁾

Bit 7 del comando 8

²⁰⁾

.tit e .tip

²¹⁾

configurabile nel file xw.conf.xml nella sezione global.conf alla voce share.dir.

²²⁾

Operazione che si effettua, di norma, subito dopo l'apertura di un archivio

²³⁾

PostKeys

²⁴⁾

La ricerca veniva fatta su un canale monovalore

²⁵⁾

In proposito si ricorda che la directory di riferimento degli allegati è nomearchivio.file e che i percorsi si intendono relativi rispetto ad essa

²⁶⁾

in quanto basata sulle capacità della libreria 'iconv'

²⁷⁾

con effetti serissimi sulla consistenza degli indici stessi

²⁸⁾

Windows Only

²⁹⁾

Grazie ad una configurazione del file xwls.conf.xml

³⁰⁾

Che corrisponde ad un singolo file, numerato progressivamente, per ciascun documento

³¹⁾

L'encoding usato per default nel fare gli indici

³²⁾

La header del file .idx manda ad una root che non esiste assolutamente

³³⁾

Lo .stat.xml cita documenti che non ci sono, appare un catalogo che conta il doppio dei documenti e la prima metà non esiste

³⁴⁾

In questo modo si privilegiano i titoli dei documenti più recenti che sono maggiormente candidati ad essere consultati

³⁵⁾

Vale a dire una stringa che indica anno, mese, giorno, ore, minuti e secondi

³⁶⁾

In questo caso, però, si paragona un server compilato debug ed uno compilato release

³⁷⁾

xw.ini

³⁸⁾

che rappresenta il numero di nodi di 512 bytes

³⁹⁾

che rappresenta un valore espresso in Kb

⁴⁰⁾

per le ragioni indicate nel punto precedente

⁴¹⁾

Che quindi vengono ignorati qualora presenti

⁴²⁾

ovviamente in sola ricerca

⁴³⁾

questa soluzione non si applica agli attributi

⁴⁴⁾

ad esempio via WatchDoc

Indice