Directory interrotta a 1.000 files

[s-curiale]

L'aggiornamento settimanale del 25 novembre dei dati Covid delle regioni non carica oltre il file n. 1.000, ovvero il 19 novembre. In cima alla pagina appare il messaggio "Sorry, we had to truncate this directory to 1,000 files. 7 entries were omitted from the list". Come fare per caricare i files dei giorni successivi?

[s-curiale]

aggiornamento. Ho risolto utilizzando il bottone "Go to file" e quindi digitando nel file finder il nome del file che volevo scaricare (es. [dpc-covid19-ita-regioni-20221124.csv). Certo se si riuscisse a ripristinare l'elenco su una sola pagina sarebbe meglio

[Giodecris]

Si possono visualizzare gli ultimi file caricati anche cliccando sul testo "Pubblicazione del 2022....." sopra l'elenco delle cartelle o sopra i file di ogni singola cartella

[Ugetto]

Il limite a 1000 files è veramente debilitante. Posso suggerire di trasferire i file degli anni 2021 e 2020 in sottocartelle specifiche in modo da ritornare ad avere meno di 1000 files per cartella.

[s-curiale]

Il limite a 1000 files è veramente debilitante. Posso suggerire di trasferire i file degli anni 2021 e 2020 in sottocartelle specifiche in modo da ritornare ad avere meno di 1000 files per cartella.

Ancora più semplice sarebbe ordinare i file dal più recente al meno recente, in modo da avere i file più aggiornati in testa alla pagina e non dover scrollare fino in fondo

[LuciferSam86]

Ciao, se non ricordo male, è solo un limite dell'interfaccia web di GitHub. Non credo che gli owner del repo possano far qualcosa.

[Ansuel]

Magari magari non usare uno strumento di sviluppo per storare dei cazzo di pdf ed utilizzare soluzioni adatte? Sai no sta roba dovrebbe essere governativa... sta repo andrebbe reportata a github per abuso dei termini di servizio

[LBreda]

Magari magari non usare uno strumento di sviluppo

Git è uno strumento di versionamento, non uno strumento di sviluppo.

[Ansuel]

Però l'abuso di usare github come uno storage gratuito non lo commentiamo eh :D

[cristianlivella]

Però l'abuso di usare github come uno storage gratuito non lo commentiamo eh :D

Non mi risulta che sia un abuso, è esattamente la funzione principale di GitHub: storage gratuito di repository GIT.

[Ansuel]

@cristianlivella quindi secondo questa logica io mi faccio il mio repo di foto vacanze e mi metto a caricare quello che voglio... non è che solo perchè github lo permette e non butti giù i repo sia giusto... dati del genere per la loro semplicità andavano gestiti diversamente e correttamente storati altrove... il versioning che si fa qui è semplicemente aggiornare dei json con i nuovi dati dei contagi... tutto il resto sono csv che vengono aggiunti... e guarda un pò il problema di seguire pratiche del genere? github giustamente ti tronca a 1000 file per non farti scoppiare il browser sul cellulare.

Quando semplicemente si poteva fare uno script automatico che caricava il csv su un server di hosting e aggiungeva il relativo link ad un file di testo se per qualche motivo una persona aveva bisogno di accedere ai dati. (idealmente facevi una static page con git o semplicemente un readme.md nella sottocartella) Corretto hosting su server e corretto versioning su github.

[MarcoBuster]

L'aggiornamento settimanale del 25 novembre dei dati Covid delle regioni non carica oltre il file n. 1.000, ovvero il 19 novembre. In cima alla pagina appare il messaggio "Sorry, we had to truncate this directory to 1,000 files. 7 entries were omitted from the list". Come fare per caricare i files dei giorni successivi?

@s-curiale Per rispondere alla domanda, il modo appropriato è clonare la repository in locale utilizzando Git con il seguente comando:

$ git clone https://github.com/pcm-dpc/COVID-19.git

Ogni settimana, se si vogliono aggiornare i dati è sufficiente entrare nella directory e scrivere

$ git pull origin master

[exogenesis18]

Gli effetti dell'utilizzo improprio di Github da parte dei non sviluppatori: https://www.repubblica.it/cronaca/2022/11/28/news/mille_giorni_di_pandemia-376468787/ quoto @Ansuel al 100%

[LuciferSam86]

Vabbè quella é pura ignoranza su come funzionano certi sistemi.

Puro giornalismo spazzatura .

Per il resto sono d'accordo al 100% con Ansuel.

[Acp66]

the solution would be simple, archive the old data in another folder, many organizations use this solution

[Ansuel]

@Acp66 Oh noooo !!!!! they want to hide the data OMG it was all a conspiracy -.- Get your shit togheder... it's just a webui limitation to not make mobile phone with low ram explode when loading the page...

@Masslor13 noto che tu push roba... consiglio spassionato... Chiudi questa Issue... Creane un'altra avvisando del problema e la procedura per accedere ai file e pinnala... (e chiudi anche le risposte) Che altrimenti inizia ad arrivare la gente strana...

[Ansuel]

@Acp66 don't be funny with me... you only intent here is to start a conspiracy talk... github is just a webui to visualize a git repository... following this rule then the linux kernel hides backdoor just because the arm dts directory limit dts to 1000 files... What happens to the other 4000? full of backdoor in your opinion... Quite the opposite in reality...

They store the data in a wrong way? Yes... They want to hide data? TOTALLY NOT AND THIS IS TOTALLY STUPID TO EVEN THINK...

But I may be wrong and it wasn't your intention after all... but I really doubt it.

[cristianlivella]

@Acp66 If you think that "they" are doing this on purpose to hide data, it means you have absolutely no idea about how Git and GitHub works.

And I quoted they because nobody chose to hide the files next to the firsts 1000, it's just a limitation of the web interface of GitHub to prevent the browser to crash or slow down too much.

Actually, by using GitHub, and not a simple web server, as @Ansuel suggested, they provide a highest confidence about the fact that these data cannot be altered without someone noticing it (who have this repository cloned on their computer will receive an error if the old data are altered, with a normal web server it would be more difficult to notice and prove it).

Probably, thinking about it right now, it would make sense to put the data in subdirectories, like yyyy/mm/[file], although I don't think it's a great idea to do it right now, as this repository is not used only by human but even by computerized tools, and all of them they would need to be updated if the structure of the directories changes.

[Ansuel]

@cristianlivella probably at times they didn't think this damn thing lasted 3 fking years....

[Acp66]

Ansuel It was absolutely not my intention to make any conspiracy theories. I'm sorry if I offended you, it was just a provocation to wake up the data managers... but now I understand that maybe you're right, if I can I delete everything

[falcomatteo]

Convengo con quanti lamentano il limite a 1000 file che non credo non possa essere ampliato e comunque esistono molte alternative per aggirare il problema. Se questo è un servizio rivolto a una vasta utenza occorre trovare un mezzo per renderlo sempre disponibile, in fondo sono informazioni che trovano ancora interesse.