Skip to main content

Come eliminare il limite di 255-260 caratteri nei path di file e cartelle in Windows 10

Introduzione

Se siete sviluppatori, sistemisti o utenti esperti in ambiente Windows è molto probabile che siate già al corrente della fastidiosa limitazione a 255-260 caratteri della dimensione di qualsiasi path di sistema – ovvero del percorso di file e cartelle. Nel caso in cui non ne abbiate mai sentito parlare, ecco un breve riepilogo:

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is “D:\some 256-character path string<NUL>” where “<NUL>” represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.) [extract from this MSDN official guide].

A ben vedere si tratta di una singolare caratteristica residuale del filesystem NTFS, che oggi come oggi non ha più senso. Al tempo stesso non si tratta di un problema che riguarda la maggior parte degli utenti standard, che raramente avranno bisogno di creare strutture di cartelle annidate così lunghe.

Le cose cambiano non poco per gli sviluppatori e gli amministratori di sistema che hanno necessità di lavorare con strumenti pensati in ottica Linux, come ad esempio il package manager NPM, il quale viene utilizzato per distribuire numerosi software e librerie che fanno un largo uso di cartelle annidate: NodeJS, AngularJS, Angular2, React, SystemJS, solo per citarne alcuni. Le cose si aggravano ulteriormente se questi strumenti vengono utilizzati all’interno di Visual Studio 2015, il quale aggiunge la propria struttura (cartella soluzione + cartella progetto + altre sotto-cartelle come /src/ , /bin/ , /node_modules/  et. al.), che aumentano a dismisura le possibilità di raggiungere il suddetto limite.

 

(altro…)

 

Password MySQL scaduta: come risolvere in modo permanente

Se vi siete imbattuti in questo articolo è molto probabile che abbiate scoperto a vostre spese la nuova funzionalità introdotta con MySQL 5.7.4 e destinata probabilmente ad essere presente in tutte le versioni successive: la scadenza automatica delle password di tutti gli account, ivi compresi quelli di amministrazione e di sistema come il classico “root”. Se siete soliti connettervi manualmente al Database è probabile che abbiate ricevuto il seguente messaggio direttamente dalla GUI del vostro client MySQL preferito (SQLyog, MySQL Workbench o qualsiasi altro):

Your password has expired. To log in you must change it using a client that supports expired passwords.

Tuttavia, i primi ad accorgersi – si fa per dire – di questo problema sono spesso i siti e servizi web come Wordrpress, Joomla, phpBB e/o qualsiasi altro che necessiti di una connesione al nostro database MySQL per funzionare. Questo significa inevitabilmente accusare un downtime che, se non si interviene prontamente, può costare caro alla nostra media di uptime mensile e farci perdere più di qualche accesso.

Come sempre, la prima cosa da fare per risolvere il problema è documentarsi: la nuova funzionalità, introdotta per ovvi motivi di sicurezza, è ampiamente illustrata nella documentazione ufficiale di MySQL 5.7, che è opportuno leggere con attenzione prima di effettuare qualsiasi cambiamento.

Immediatamente dopo, possiamo passare all’azione. La scelta, che dobbiamo effettuare responsabilmente sulla base di quanto appreso dalla documentazione ufficiale, è se limitarsi a cambiare password ai nostri account MySQL – abituandoci a farlo spesso e di frequente – oppure disattivare la scadenza automatica. Inutile dire che non c’è una scelta migliore o peggiore, tutto dipende dal nostro scenario di impiego. E’ probabile che, come spesso accade in questi casi, la verità si trovi nel mezzo: nel caso in cui l’account MySQL è relativo a un operatore o amministratore, è senz’altro preferibile lasciare che la password scada periodicamente, così da essere “costretti” a cambiarla di frequente: un’ottima abitudine per ridurre al minimo i rischi legati a possibili perdite o furti di password (da parte nostra o dei nostri collaboratori) e, di conseguenza, possibili accessi non autorizzati. Al tempo stesso, se l’account è di sistema – ad esempio quello utilizzato da un sito o servizio web – è probabile che la scelta più logica sia quella di disattivare la scadenza automatica, magari limitando con l’occasione i permessi di tale account.

Cosa fare nel caso degli account utilizzato sia da servizi di sistema che da operatori? La risposta è molto semplice: è la buona occasione per liberarci definitivamente da questo tipo di account, che non dovrebbero esistere in un sistema organizzato secondo il buon senso: nessun account di sistema dovrebbe essere utilizzato anche per effettuare un accesso mauale e viceversa, secondo il ben noto principio della Separation of Duties. Potremmo dire che uno dei meriti principali di questa nuova funzionalità di MySQL è proprio quello di costringere tutti gli amministratori di sistema a rivedere la logica alla base degli account creati, facendo chiarezza una volta per tutte sul ruolo attribuito a ciascuno di essi e limitandone lo scope di conseguenza.

Tutto ciò premesso, vediamo come possiamo intervenire per risolvere il nostro problema. Nel caso in cui fossimo ancora in grado di accedere con un account con privigilegi di amministratore – come ad esempio l’account root – la soluzione sarebbe fin troppo ovvia: basterebbe effettuare il login con l’account in questione e cambiare la password scaduta. Esistono però almeno due situazioni che richiedono l’esecuzione di azioni diverse e/o aggiuntive:

 

  • Se anche la nostra password di amministrazione / root è scaduta.
  • Se vogliamo disabilitare la scadenza della password per uno o più account.

Lo scopo di questo articolo è quello di fornire tutte le informazioni necessarie per il conseguimento di questi risultati.

(altro…)

 

Impossibile avviare il debug sul server Web con Visual Studio 2015 – Come risolvere

Lavorare con Visual Studio sulle versioni più recenti di Windows, come ad esempio Windows 10, può non essere sempre facile: il motivo è spesso legato alle nuove impostazioni di sicurezza che caratterizzano il nuovo sistema e che bloccano l’accesso a molti elementi normalmente necessari ai software di sviluppo, come l’accesso in scrittura alla cartella /Program Files/, ai file di configurazione di IIS Express, alla IIS metabase e via dicendo.

A fare le spese di tutto questo è molto spesso proprio IIS Express, prodotto che già da diversi anni è scivolato ai margini  del disinteresse di casa Microsoft in favore di soluzioni più moderne (come Kestrel, come ben sanno gli sviluppatori .NET Core) ed è costantemente flagellato da problemi di vario tipo. Alcuni di questi sono già stati affrontati in questa sede, come ad esempio in questo articolo sull’impossibilità di accedere alla IIS Metabase, in questo articolo dedicato al problema delle external request e in questo approfondimento sull’errore ‘Process with an ID #### is not running’.

In questo articolo parleremo di un altro errore frequente che può capitare lavorando con una soluzione ASP.NET Core o ASP.NET MVC, immediatamente dopo aver provato a lanciare l’applicazione in modalità debug:

Impossibile avviare il debug sul server Web

Fortunatamente esistono diversi workaround che possono risolvere questo tipo di errore: suggeriamo di provarli uno dopo l’altro, fermandosi soltanto quando si riesce a trovare quello che consente di risolvere il problema.

(altro…)

 

Process with an ID #### is not running con Visual Studio 2015 – Come risolvere

Lavorare con Visual Studio sulle versioni più recenti di Windows può portare occasionalmente a qualche problema per via delle nuove impostazioni di sicurezza che caratterizzano il nuovo sistema: queste ultime, che prevedono un accesso limitato alle risorse normalmente disponibili all’account assegnato al software in esecuzione, bloccano l’accesso a molti elementi normalmente necessari agli strumenti di sviluppo: l’accesso in scrittura alla cartella /Program Files/, ai file di configurazione di IIS Express, alla IIS metabase e una serie di altre task che possono portare al malfunzionamento di alcuni strumenti, come ad esempio IIS Express. Alcuni di questi sono già stati affrontati in questa sede, come ad esempio in questo articolo sull’impossibilità di accedere alla IIS Metabase, in questo articolo dedicato al problema delle external request e in questo approfondimento sull’errore ‘Impossibile avviare il debug sul server Web’.

In questa occasione parliamo del seguente errore, che può verificarsi nel momento di aprire una soluzione ASP.NET Core o ASP.NET MVC o di lanciare l’applicazione in modalità DEBUG:

Impossibile avviare il debug sul server Web

Process with an ID #### is not running on Visual Studio 2015

In conseguenza di questo errore, nella finestra degli errori di Visual Studio dovrebbe essere possibile reperire altre informazioni, come ad esempio queste:

Fortunatamente esistono diversi workaround che possono risolvere questo tipo di errore: suggeriamo di provarli uno dopo l’altro, fermandosi soltanto quando si riesce a trovare quello che consente di risolvere il problema.

(altro…)

 

Come impedire a MailPoet di contare gli utenti WordPress come Subscriber e far funzionare correttamente le limitazioni della versione gratuita

Non c’è operatore, gestore o amministratore WordPress che non conosca MailPoet, precedentemente noto come WYSIJA: per dirla in breve, si tratta di uno dei più sofisticati plugin WordPress per la gestione delle newsletter, utilizzato da migliaia – se non milioni – di siti e blog in tutto il mondo per la sua grande quantità di opzioni e funzionalità.

Personalmente ritengo MailPoet un plugin assolutamente eccezionale: fa parte di quella esigua lista di plugin che includo in quasi tutte le installazioni WordPress che mi capita di gestire o amministrare (inclusa questa). Nella maggior parte dei casi si tratta di siti piccoli: in alcuni casi – quando gli utenti e i subscriber delle newsletter sono migliaia – ho anche consigliato l’acquisto della licenza premium, non soltanto perché si tratta di un prodotto ampiamente meritevole del supporto degli utenti, ma anche perché… beh, perché la licenza gratuita ha una limitazione di 2000 subscriber, raggiunti i quali occorre pagare. Il plugin ha anche un counter interno che provoca la disabilitazione di tutte le newsletter quando il numero dei sottoscrittori raggiunge o supera i 2000.

Come ho detto, ritengo MailPoet un componente eccezionale… ad eccezione di un singolo, grande difetto: il subdolo stratagemma che gli sviluppatori hanno ideato per spingere l’amministratore WordPress a pagare per attivare la licenza premium, anche quando non ne ha alcun bisogno reale.

(altro…)