Penso che, come me, ti sia capitato di vedere percorsi di questo tipo !!! Importante____Nuovo____!!! Non eliminare!!! Decreto n. 98819-649-B del 30 febbraio 1985 riguardante la nomina di Ivan Aleksandrovich Kozlov come supplente temporaneo del responsabile della gestione dei clienti VIP aziendali e dell'organizzazione di incontri d'affari nei corridoi.doc.
E spesso aprire un documento di questo tipo su Windows non è possibile immediatamente. Alcuni utilizzano un workaround come la mappatura delle unità, altri usano gestori di file capaci di gestire percorsi lunghi: Far Manager, Total Commander e simili. E molti hanno tristemente osservato come uno script PS creato con grande impegno, che funzionava alla grande in ambiente di test, lamentasse impotente un compito difficile in produzione: Il percorso specificato, il nome del file, o entrambi sono troppo lunghi. Il nome del file completamente qualificato deve essere inferiore a 260 caratteri e il nome della directory deve essere inferiore a 248 caratteri.
Come si è scoperto, 260 caratteri non sono "un limite per tutti". Se sei interessato a superare i confini consentiti, ti prego di proseguire.
Ecco solo alcune delle tristi conseguenze del limite della lunghezza del percorso del file:
- sul server c'è una cartella, ad esempio, D:DataSharedAccounting, condivisa tramite SMB e montata dagli utenti come disco di rete S; gli utenti creano file che non possono essere letti dagli amministratori/scritti quando accedono localmente al server, poiché il percorso assoluto risulta più lungo rispetto al percorso di rete;
- ;
- ;
- quando si migra dati da altri sistemi con requisiti meno rigidi sulla lunghezza del percorso, in un nuovo ambiente, parte di essi diventerà inaccessibile senza complicati passaggi;
- ;
- ecc...
Allontanandomi leggermente dall'argomento, vorrei sottolineare che per la replica DFS il problema trattato nell'articolo non è grave e i file con nomi lunghi viaggiano con successo da server a server (se, ovviamente, avete fatto tutto correttamente) ).
Vorrei anche sottolineare un'utilità molto utile che mi ha spesso salvato . Non ha paura dei percorsi lunghi e sa fare molte cose. Quindi, se il compito consiste in copiare/spostare dati, si può fermarsi a questo. Se è necessario lavorare con le liste di controllo degli accessi nel file system (DACL), è consigliabile guardare in direzione di . Nonostante la sua età, ha dimostrato di essere eccellente su Windows 2012 R2. sono stati considerati metodi di applicazione.
E a me interessava insegnare a usare PowerShell con percorsi lunghi. È quasi come nell'antica barzelletta su Ivan Tsarevich e Vasilisa la Bella.
Metodo veloce
Passare a Linux e non preoccuparsi di Windows 10/2016/2019 e abilitare il parametro della policy di gruppo/tweaker il registro. Non mi soffermerò su questo metodo, in quanto ci sono già molti articoli online su questo tema, ad esempio, .
Tenendo conto che nella maggior parte delle aziende ci sono molte versioni di sistemi operativi, per non dire obsolete, questo metodo è solo veloce sulla carta, a meno che non siate tra i fortunati con poche legacy system e siate assediati da Windows 10/2016/2019.
Metodo lungo
Ci teniamo a precisare che le modifiche non influenzeranno il comportamento di Esplora file di Windows, ma consentiranno di utilizzare percorsi lunghi nei cmdlet di PowerShell, come Get-Item, Get-ChildItem, Remove-Item e altri.
Iniziamo aggiornando PowerShell. È semplice e veloce.
- Aggiorniamo .NET Framework alla versione 4.5 o superiore. Il sistema operativo deve essere almeno Windows 7 SP1/2008 R2. Puoi scaricare l'ultima versione , leggi ulteriori informazioni .
- e installiamo Windows Management Framework 5.1
- Riavviamo il computer.
I più laboriosi possono eseguire i passaggi sopra descritti manualmente, mentre i più pigri possono farlo usando SCCM, politiche, script e altri strumenti di automazione.
La versione attuale di PowerShell può essere trovata nella variabile $PSVersionTable. Dopo l'aggiornamento dovrebbe risultare simile a questo:

Ora, utilizzando cmdlet Get-ChildItem e simili, invece del consueto Path useremo LiteralPath.
Il formato dei percorsi sarà leggermente diverso:
Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"
Per facilitare la conversione dei percorsi dal formato abituale al formato LiteralPath puoi utilizzare la seguente funzione:
Funzione ConvertTo-LiteralPath
Param([parameter(Mandatory=$true, Position=0)][String]$Path)
Se ($Path.Substring(0,2) -eq "") {Return ("?UNC" + $Path.Remove(0,1))}
Altrimenti {Return "?$Path"}
}
Si prega di notare che quando si imposta il parametro LiteralPath non è possibile utilizzare caratteri jolly (*, ? e così via).
Oltre al parametro LiteralPath, nella versione aggiornata di PowerShell, il cmdlet Get-ChildItem ha ricevuto il parametro Depth, che consente di impostare la profondità di annidamento per la ricerca ricorsiva, l'ho utilizzato un paio di volte e sono rimasto soddisfatto.
Ora non c'è bisogno di temere che il tuo script PS perda il lungo e difficile cammino e non riesca a vedere i file lontani. A me, ad esempio, è molto utile questo approccio nella scrittura di uno script per rimuovere l'attributo "temporaneo" dai file nelle cartelle DFSR. Ma questa è un'altra storia, di cui cercherò di parlare in un altro articolo. Aspetto i vostri interessanti commenti e vi invito a partecipare al sondaggio.
Link utili:
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Il problema dei percorsi lunghi è rilevante per te?
Sì
Era rilevante, ma l'ho già risolto
Dà fastidio, ma non troppo
Non ci avevo pensato, sembra che tutto funzioni
No
Altro (specificare nei commenti)
155 utenti hanno votato. 25 utenti si sono astenuti.
Fonte: habr.com
