Gestione accesso INI file

di il
17 risposte

Gestione accesso INI file

Ciao,

utilizzo degli INI files per passare dei parametri da un client Windows a un servizio Windows. Il client salva il file INI in una cartella secondaria e il servizio, ad ogni inizio del loop, verifica la presenza di un file, lo sposta nella cartella principale e carica i parametri contenuti.

Delle volte però, il file INI spostato risulta incompleto contenente solo parte dei parametri. Un malfunzionamento che pare risolto dopo l'implementazione di una funzione ("WaitForFileComplete(INIPath)") nel servizio che verifica la dimensione del file INI e quindi fa in modo che il file INI non venga spostato finché non è completo, una funzione chiamata due volte nel servizio: (1) prima di spostare il file INI dalla cartella secondaria alla principale e (2) prima di aprire il file INI per leggere i parametri.

if TFile.Exists(UpdatePath) then
  begin
    if TFile.Exists(Path) then
      TFile.Delete(Path);
    WaitForFileComplete(UpdatePath);  //(1)
    TFile.Move(UpdatePath, Path);
    WaitForFileComplete(Path);  //(2)
    if TFile.Exists(Path) then
      begin
        Ini := TIniFile.Create(Path);
        try
          ...
        finally
          freeandnil(Ini);
        end;
      end;
  end;

Fin'ora pare funzionante. Per utilizzare al meglio i files INI Vorrei cmq chiedervi perché lo stesso servizio procede col codice aprendo l'INI file senza attendere il termine di TFile.Move.

Mille grazie, Ale

17 Risposte

  • Re: Gestione accesso INI file

    06/09/2023 - al.delphi ha scritto:


    utilizzo degli INI files per passare dei parametri da un client Windows a un servizio Windows. Il client salva il file INI in una cartella secondaria e il servizio, ad ogni inizio del loop, verifica la presenza di un file, lo sposta nella cartella principale e carica i parametri contenuti.

    I file INI hanno tutt'altro scopo: utilizzarli a questi fini è come volersi andare a cercare dei problemi, quando esistono soluzioni ben più efficaci e pulite. Banalmente, meglio usare un database, o inviare un messaggio all'applicazione… qualunque cosa è meglio di questa.

    06/09/2023 - al.delphi ha scritto:


    Fin'ora pare funzionante. Per utilizzare al meglio i files INI Vorrei cmq chiedervi perché lo stesso servizio procede col codice aprendo l'INI file senza attendere il termine di TFile.Move.

    Ma la funzione WaitForFileComplete l'hai scritta tu? In ogni caso, probabilmente il file non è bloccato per l'apertura nel momento in cui ha inizio lo spostamento, e questo consente di leggerlo, ma bisogna approfondire come agiscono le funzioni che stai utilizzando, al netto che - ripeto - sono tutti mal di pancia che eviterei usando gli strumenti giusti per questo genere di scopi.

  • Re: Gestione accesso INI file

    Al di là del modo sbagliato di usare il file, la procedura per aggiornare un file e'

    1. se presente, cancellare il file. new
    2. creare il file. new
    3. se presente, cancellare il file. bak
    4. rinominare il file. ini in. bak
    5. rinominare. new in .ini
    6. cancellare. bak

    in questo modo:

    1. se. ini e' presente, ok
    2. se. bak e' presente, usa. bak
    3. non ci puo' essere un. new parziale e la mancanza di un. ini o un. bak

    questo perche

    1. . new potrebbe non essere completo
    2. il sistema si potrebbe essere impiantato tra i rename

    ovviamente devi assicurarti che tutto venga fatto in modo che qualunque eccezione non completi tutti i passaggi. 

  • Re: Gestione accesso INI file

    06/09/2023 - Alka ha scritto:


    I file INI hanno tutt'altro scopo: utilizzarli a questi fini è come volersi andare a cercare dei problemi, quando esistono soluzioni ben più efficaci e pulite. Banalmente, meglio usare un database, o inviare un messaggio all'applicazione… qualunque cosa è meglio di questa

    “..meglio un database..”  non credo proprio, un aumento complessita' inutile, almeno in questo caso

    La SOLUZIONE e' ovviamente l'invio diretto di un messaggio da programma a programma, ma piu' semplice ancora da realizzare e' l'uso di un file ini o altro file di testo

    Non e' ben chiaro perche' dici che l'uso di un file INI sia sconsigliato, se a lui basta questo e' uno dei sistemi piu' semplici che esistano per passare informazioni da una procedura ad un'altra, facilmente verificabile, modificabile con un editor di testo, ecc..

  • Re: Gestione accesso INI file

    07/09/2023 - amorosik ha scritto:


    “..meglio un database..”  non credo proprio, un aumento complessita' inutile, almeno in questo caso

    L'unica complessità che aumenta è quella della struttura del file, mentre per il resto il codice sarebbe del tutto equivalente: invece di aprire un file di testo specificandone il percorso si andrebbe ad aprire un file di database locale (es. SQLite o affine), invece di leggere valori di setting da sezioni di un file di testo si andrebbe a leggere il valore di un campo tipizzato da una tabella… ai fini della codifica, soprattutto in Delphi, il codice da scrivere sarebbe identico e non ci sarebbero complessità particolari da dover gestire.

    Anzi, il beneficio derivante dal fatto che il database gestisce per lo sviluppatore eventuali lock di record, o snapshot di valori per poterli leggere mentre sono in modifica dall'altra parte, eviterebbe di mettere in piedi il workflow proposto da migliorabile, che condivido pienamente e che - usando dei semplici file - è sostanzialmente l'unico modo sicuro e affidabile per poter implementare quanto è richiesto, se si sceglie di usare un semplice file di testo.

    07/09/2023 - amorosik ha scritto:


    La SOLUZIONE e' ovviamente l'invio diretto di un messaggio da programma a programma, ma piu' semplice ancora da realizzare e' l'uso di un file ini o altro file di testo

    Io infatti punterei a imbastire un meccanismo di comunicazione tra processi o con un sistema di messaggistica, ma comprendo anche la necessità di tenere le cose semplici, motivo per cui non ho approfondito né suggerito questa strada. Detto questo, visto che si vuole utilizzare un semplice file per questa comunicazione, tanto vale usare un formato più strutturato del file INI, e che magari possa gestire nativamente (grazie ai clienti già disponibili) le funzionalità richieste, cosa che un file INI invece non fa, visto che è stato creato per altri scopi.

    Oltre a questo, ci aggiungo anche un fattore di minima apertura verso quelle che potrebbero essere necessità future: se uso un database, posso scegliere cosa caricare dalla tabella delle “informazioni” da passare, posso prelevare le cose da fare e contrassegnarle come “fatte”, posso tenere uno “storico” con poco sforzo, un domani posso migrare lo stesso file a una architettura più complessa (es. client/server), in breve ho una rosa di possibilità più ampie che potrei sfruttare.

    Non è detto che quelle indicate sopra siano esigenze richieste per forza, anzi magari non diventeranno mai necessarie, ma intanto dovendo caricare informazioni da un file fisico, quantomeno si è scelto un formato che da senz'altro maggiori potenzialità, al costo (zero) di scrivere lo stesso codice praticamente equivalente dal punto di vista della lunghezza e della complessità.

    07/09/2023 - amorosik ha scritto:


    Non e' ben chiaro perche' dici che l'uso di un file INI sia sconsigliato, se a lui basta questo e' uno dei sistemi piu' semplici che esistano per passare informazioni da una procedura ad un'altra, facilmente verificabile, modificabile con un editor di testo, ecc..

    Mi pare di aver argomentato, poi si può essere d'accordo o meno, in base ai propri gusti e attitudini.

    Per concludere, i file INI si chiamano “INI” proprio perché hanno un preciso obiettivo: riportare i comandi di inizializzazione di un programma che provvede a leggerli all'avvio.

    Usi di altro tipo possono senz'altro esistere, ma (a mio parere s'intende) sono un “piegarli” a fare qualcosa che normalmente non dovrebbero fare, e almeno personalmente prediligo formati di file (o scambi di messaggi) più strutturati, basati su testo ma tipizzati, oppure anche binari come quelli di tanti database di tipo “file based”.

    Certo, questi ultimi non sono leggibili con un blocco note come i file INI, ma basta uno dei tanti client opensource disponibili per determinati file per accedere ai dati, visualizzarli e modificarli, sfruttando tutta una serie di facilitazioni (verifiche di validità, vincoli di chiave, ecc.) che rendono il tutto meno “error prone” senza richiedere allo sviluppatore sforzi aggiuntivi, anzi semplificandone il lavoro.

  • Re: Gestione accesso INI file

    Se i file INI sono nati per un intento preciso, non e' detto che non si possa usarli per altro

    E quindi, non e' ben chiaro (almeno a me) il motivo per cui dici ‘sono sconsigliabili’

    In questo caso, a mio avviso, sono perfetti perche' uniscono la semplicita' nel leggerli/scriverli con la flessibilita' della strutturazione in chiave/valore

    Per quanto riguarda l'uso di un db, di qualsiasi tipo, per scambiare qualche riga di valori, va beh soprassediamo

  • Re: Gestione accesso INI file

    07/09/2023 - amorosik ha scritto:


    Se i file INI sono nati per un intento preciso, non e' detto che non si possa usarli per altro

    Infatti, non ho detto questo.

    07/09/2023 - amorosik ha scritto:


    E quindi, non e' ben chiaro (almeno a me) il motivo per cui dici ‘sono sconsigliabili’

    Come dicevo, mi pare di aver argomentato, ma può anche darsi che non lo abbia fatto a sufficienza: se c'è qualcosa da approfondire, basta dirlo e lo snoccioliamo.

    Continuare a ripetere che “non è chiaro” senza dettagliare, da un lato, oppure criticarmi dicendo l'ovvio ossia che posso usare i file INI in altri modi, che non è quello che ho detto, non serve a nulla.

    07/09/2023 - amorosik ha scritto:


    In questo caso, a mio avviso, sono perfetti perche' uniscono la semplicita' nel leggerli/scriverli con la flessibilita' della strutturazione in chiave/valore

    Ok, mi sta bene.

    Io invece, come ho già detto, se devo usare file di testo per passare informazioni tra programmi, e quindi gestirmi le dinamiche di “blocco” su aggiornamento, lettura, scrittura e rinomina, per evitare di non riuscire a scriverli perché in lettura o leggerli parzialmente perché in scrittura, preferisco usare un database, sempre basato su file fisico (non client/server), che in Delphi si gestisce più o meno allo stesso modo, ma che mi aiuta di più in queste occasioni, in quanto già progettato per condividere dati tra applicazioni con possibili accessi concorrenti, sacrificando nel “trade off” (perché c'è sempre un compromesso) la possibilità di aprirlo nel blocco note, con la fatica di aprirlo invece con un altra utility dedicata, che nel 2023 in cui viviamo si trova ovunque e anche opensource.

    07/09/2023 - amorosik ha scritto:


    Per quanto riguarda l'uso di un db, di qualsiasi tipo, per scambiare qualche riga di valori, va beh soprassediamo

    “Soprassediamo"…  ok, però non sono io che continuo a scrivere messaggi di due righe, ribadendo sempre le stesse cose ossia che “non è chiaro”, senza argomentare al netto delle due cose che hai già ribadito e a cui ho già risposto dando il mio parere, sul quale si può essere d'accordo oppure no.

    Se si vuole discutere bene, se non si vuole discutere amen.
    Possiamo anche pensarla diversamente senza che ci debba essere una convergenza.

    Continuare a “imbeccare” senza aggiungere nulla o lamentando una mancanza di chiarezza alla terza volta che spiego le stesse identiche cose, senza poi andare a contestare nel merito, serve solo ad alimentare un “flame” e non apporta nulla di costruttivo alla discussione, e non ho assolutamente voglia di perdere tempo in questo, soprattutto parlando di file INI. :)

  • Re: Gestione accesso INI file

    A me è capitata la stessa cosa, dover far comunicare una app vcl con un servizio windows, ho usato tclientsocket per la comunicazione, gli dai in pasto indirizzo e porta e basta, gestisci gli eventi socketconnect,socketread ecc… e lato app mandi i comandi… piu facile a farsi che a dirsi, prova a dare un occhio.

    comunque nel caso io avrei scelto la strada di Marco, un db sqlite al limite, è comunque un file di testo ma viene gestito automaticamente diciamo, ti levo un sacco di problematiche, oltre alla comodità di avere un eventuale storico, una gran bela personalizzazione ecc ecc…

  • Re: Gestione accesso INI file

    11/09/2023 - ziobacco ha scritto:


    A me è capitata la stessa cosa, dover far comunicare una app vcl con un servizio windows, ho usato tclientsocket per la comunicazione, gli dai in pasto indirizzo e porta e basta, gestisci gli eventi socketconnect,socketread ecc… e lato app mandi i comandi… piu facile a farsi che a dirsi, prova a dare un occhio.

    comunque nel caso io avrei scelto la strada di Marco, un db sqlite al limite, è comunque un file di testo ma viene gestito automaticamente diciamo, ti levo un sacco di problematiche, oltre alla comodità di avere un eventuale storico, una gran bela personalizzazione ecc ecc…

    Perche' dici che un file Sqlite e' un file di testo?

  • Re: Gestione accesso INI file

    Un file di sqlite non è un file di testo

  • Re: Gestione accesso INI file

    Nell'era in cui si installano programmi avuto con la raccolta punti delle merendine capita spesso di disinstallare un programma e ricevere il messaggio “sono presenti file ini, vuoi cancellarli?”.

    Se proprio vuoi un file testuale, io userei un file dat.

  • Re: Gestione accesso INI file

    11/09/2023 - oregon ha scritto:


    Un file di sqlite non è un file di testo

    Secondo me, voleva intendere altro ma ha sbagliato a scrivere. Sarà un lapsus.

    11/09/2023 - sihsandrea ha scritto:


    Nell'era in cui si installano programmi avuto con la raccolta punti delle merendine capita spesso di disinstallare un programma e ricevere il messaggio “sono presenti file ini, vuoi cancellarli?”.

    Sarà un mio limite, ma io non riesco mai a capire i tuoi esempi. :)

    In ogni caso, quel messaggio fa parte di qualche programma di installazione, quindi apparirebbe se previsto esplicitamente dall'utility che usi per creare il pacchetto di installazione del programma, ma non vedo perché farlo; e se lo si fa appositamente, allora ha senso che l'estensione usata sia quella.

    Gli unici altri contesti in cui appare un messaggio simile in cancellazione è quando si parla di file INI di sistema come quelli di Windows (es. desktop.ini), ma è tutta un'altra questione.

    In sintesi, non trovo che queste siano limitazioni valide per NON usare un file INI.

    11/09/2023 - sihsandrea ha scritto:


    Se proprio vuoi un file testuale, io userei un file dat.

    Che formato è il DAT? Tu stai parlando dell'estensione, che è un'altra cosa. Nel thread si stava parlando specificatamente del file come formato di file in sé, a prescindere dall'estensione che gli viene data. Puoi chiamarlo anche .CFG, .PIPPO, ma anche .INI se si tratta di un file INI. Non ci sono problemi di sorta e l'estensione in sé non comporta problemi, o non è parte del problema che si stava affrontando/discutendo.

  • Re: Gestione accesso INI file

    11/09/2023 - Alka ha scritto:


    Sarà un mio limite, ma io non riesco mai a capire i tuoi esempi. :)

    Nel senso che mi capita spesso di vedere prodotti sw che fanno uso improprio di file ini anche se contengono tutt'altro ma generano sempre (o quasi) quella domanda sulla rimozione. A quel punto, nel dubbio lo lascio senza rimuoverlo, specie se li piazzano su system, aumentando i files spazzatura. Era una battuta non un esempio)

    Per fortuna anche windows ha abbandonato l'uso dei files ini. Speriamo che in futuro non si cominci ad intasare i files di registro di windows. (Battuta)

    06/09/2023 - Alka ha scritto:


    I file INI hanno tutt'altro scopo: utilizzarli a questi fini è come volersi andare a cercare dei problemi, quando esistono soluzioni ben più efficaci e pulite. Banalmente, meglio usare un database, o inviare un messaggio all'applicazione… qualunque cosa è meglio di questa.

    Intendevi escluso un file dat?

    11/09/2023 - Alka ha scritt


    Che formato è il DAT? Tu stai parlando dell'estensione, che è un'altra cosa. Nel thread si stava parlando specificatamente del file come formato di file in sé, a prescindere dall'estensione che gli viene data. Puoi chiamarlo anche .CFG, .PIPPO, ma anche .INI se si tratta di un file INI. Non ci sono problemi di sorta e l'estensione in sé non comporta problemi, o non è parte del problema che si stava affrontando/discutendo.

    Proprio perché puoi chiamarlo come vuoi o addirittura usare sqlite e, visto che un tale ha detto:

    07/09/2023 - Alka ha scritto:


    Mi pare di aver argomentato, poi si può essere d'accordo o meno, in base ai propri gusti e attitudini.

    Io dico la mia. Meglio usare il db o un file criptato.

    L'ultimo dubbio che mi resta è il perché andare nella posizione x copiare il file nella posizione y e lavorare in quella posizione.

  • Re: Gestione accesso INI file

    11/09/2023 - sihsandrea ha scritto:


    Nel senso che mi capita spesso di vedere prodotti sw che fanno uso improprio di file ini anche se contengono tutt'altro

    Boh, io non ho mai incontrato un software che faccia uso di file INI, con estensione “.ini”, che contengano roba diversa da un formato INI.
    E quando dico mai, intendo proprio mai.

    11/09/2023 - sihsandrea ha scritto:


    ma generano sempre (o quasi) quella domanda sulla rimozione.

    Sei sicuro? Io penso di non vederla almeno dal '99.

    11/09/2023 - sihsandrea ha scritto:


    A quel punto, nel dubbio lo lascio senza rimuoverlo, specie se li piazzano su system, aumentando i files spazzatura. Era una battuta non un esempio)

    File INI nei percorsi di sistema non si mettono già da prima di Windows Vista. Parliamo di più di 15 anni fa, praticamente un'era geologica in termini informatici. Ma poi, non mi è chiaro qual è la relazione tra le tue problematiche con software vecchi che usano male file INI con il fatto di usare un file di testo con il formato INI in software nuovi. Questi aspetti che stai citando non hanno una correlazione col problema di cui si parlava.

    11/09/2023 - sihsandrea ha scritto:


    Speriamo che in futuro non si cominci ad intasare i files di registro di windows.

    Veramente, il Registro di Windows è anch'esso in uso da un ventennio, e l'instasamento è già una realtà da parecchi anni, sebbene relativamente meno problematico. Adesso è una prassi più seguita quella delle cartelle sotto “AppData”, almeno per i software più nuovi, per una questione di maggiore portabilità e flessibilità. Ma di nuovo, siamo OT (oltre a non aver capito la battuta).

    11/09/2023 - sihsandrea ha scritto:


    Intendevi escluso un file dat?

    Non so cosa sia questo file DAT. Io uso l'estensione DAT per il salvataggio di dati binari in formato custom e non appartenente ad alcun formato standard specifico, scenario che ultimamente mi capita praticamente mai.

    11/09/2023 - sihsandrea ha scritto:


    Proprio perché puoi chiamarlo come vuoi o addirittura usare sqlite

    Salvo utilizzi specifici (es. aprire il file con un doppio clic, per cui si guarda l'estensione, almeno su Windows), qualunque file puoi chiamarlo come vuoi, a prescindere dal contenuto.

    11/09/2023 - sihsandrea ha scritto:


    Io dico la mia. Meglio usare il db o un file criptato.

    Un DB - ovviamente molto semplice, come appunto SQLite o affini, che non richieda dipendenze particolari - era il mio suggerimento (non ripeto i motivi di nuovo). Ma è un gusto, ognuno scelga quel che vuole. Io ho argomentato in seguito solo perché optare per un semplice DB non mi sembrava qualcosa di così astruso, soprattutto considerando il “gioco dei tre cappelli” che bisogna fare copiando e spostando i file.

    Sul file criptato, credo avrebbe senso usarlo se ci sono informazioni sensibili, ma anche qui, se ho a che fare con informazioni sensibili, allora non andrei mai a metterli in quel file. Lo scopo dichiarato era quello di “passare parametri da un'applicazione a un'altra”, quindi si stava parlando di un ambito specifico.

    11/09/2023 - sihsandrea ha scritto:


    L'ultimo dubbio che mi resta è il perché andare nella posizione x copiare il file nella posizione y e lavorare in quella posizione.

    Mmm… eeeh?! Io non capisco… :)

  • Re: Gestione accesso INI file

    Ziovini, un DBMS non e' necessariamente un modo migliore per passare informazioni da un processo ad un'altro.

    E' solo uno dei tanti modi per farlo. 

    UN file  Sqlite non e' esente dagli stessi problemi di un normale file di testo. 

    Il file INI NON E' una cattiva scelta, e' uno dei TANTI FORMATI possibili. 

    Alternative? 

    1. XML, ovviamente
    2. JSON, altrettanto ovviamente
    3. properties file (quello di Java) 
    4. LISP: esattamente, non e' obbligatorio che sia un programma
    5. un semplice file di testo con una struttura custom
    6. TOML
    7. YAML
    8. CSV: magari i  certi casi va bene anche questo
    9. TSV: variante di un CSV
    10. PAWK

    .  

    di formati ‘strutturati’ umanamente leggibili ne esistono un bel po'. 

    Si poteva usare qualcosa di meglio del file INI? Che ne so, usare qualche protocollo di rete (TCP/IP, UDP, PGM, HTTP, AMQP,…)? 

    Magari anche si, ma tutto dipende da che cosa voglia dire ‘meglio’ .

    Nota: non so quanti conoscano il PGM, ma e' un protocollo mooolto interessante: 
    e' basato su UDP MA assicura che che non si perdano pacchetti ;-)
    Praticamente in TCP/IP ma moolto piu' leggero.

Devi accedere o registrarti per scrivere nel forum
17 risposte