Credo che, come me, ti sia capitato più volte di vedere percorsi del tipo !!! Importante____Nuovo____!!! Non cancellare!!! Ordinanza №98819-649-Б del 30 febbraio 1985 riguardante la nomina di Kozlov Ivan Aleksandrovich a responsabile temporaneo della direzione per il supporto di clienti VIP aziendali e organizzazione di incontri d'affari nei corridoi.doc.
E spesso aprire un documento del genere in Windows non è immediato. Alcuni praticano workaround come la mappatura delle unità, altri utilizzano gestori di file capaci di lavorare con percorsi lunghi: Far Manager, Total Commander e simili. E molti hanno osservato con tristezza come lo script PS che avevano creato, nel quale avevano investito non poco impegno e che funzionava perfettamente in ambiente di test, in produzione, si lamentasse impotente di un compito insormontabile: Il percorso specificato, il nome del file, o entrambi sono troppo lunghi. Il nome file completo deve essere inferiore a 260 caratteri e il nome della directory deve essere inferiore a 248 caratteri.
Come si è scoperto, 260 caratteri non sono sufficienti "per tutti". Se ti interessa superare i limiti consentiti, ti invito a continuare.
Ecco solo alcune delle tristi conseguenze della limitazione della lunghezza del percorso del file:
- sul server c'è una cartella, ad esempio, D:DataSharedAccounting, che è condivisa tramite SMB e montata per gli utenti come unità di rete S; gli utenti creano file che non possono essere letti dagli amministratori/script in accesso locale al server, poiché il percorso assoluto risulta più lungo di quello di rete;
- ;
- ;
- nella migrazione dei dati da altri sistemi, in cui ci sono meno rigide limitazioni sulla lunghezza del percorso, in un nuovo ambiente parte di essi diventerà inaccessibile senza fare passi complicati;
- ;
- ecc…
Allontanandomi leggermente dall'argomento, osservo che per la replica DFS il problema trattato nell'articolo non è grave e i file con nomi lunghi viaggiano senza problemi da server a server (se, ovviamente, nel resto avete fatto tutto bene) ).
Vorrei anche sottolineare un'utility molto utile che mi ha spesso salvato . Anche per lei i lunghi percorsi non sono un problema, e sa fare molte cose. Quindi, se il compito è limitato alla copia/spostamento di dati, si può rimanere su di lei. Se bisogna fare qualche magia con le liste di controllo accesso nel sistema di file (DACL), guarda in direzione di . Nonostante l'età rispettabile, si è comportata eccellentemente su Windows 2012 R2. sono stati esaminati i metodi di applicazione.
A me interessava insegnare a lavorare con i lunghi percorsi in PowerShell. È un po' come nella barzelletta sul principe Ivan e la bellissima Vasilisa.
Metodo veloce
Passare a Linux e non doversi preoccupare di Windows 10/2016/2019 e attivare il parametro di gruppo giusto/giocare con il registro. Non mi soffermerò su questo metodo, poiché ci sono già molti articoli online a riguardo, per esempio, .
Considerando che nella maggior parte delle aziende ci sono molte versioni di sistemi operativi, per usare un eufemismo, non freschissime, questo metodo è veloce solo sulla carta, a meno che non siate tra i pochi fortunati con poche legacy-systems dove regnano Windows 10/2016/2019.
Metodo lungo
Chiarisco subito che le modifiche non influenzeranno il comportamento di Esplora file di Windows, ma permetteranno di utilizzare percorsi lunghi nei cmdlet di PowerShell, come Get-Item, Get-ChildItem, Remove-Item e altri.
Innanzitutto aggiorniamo PowerShell. Si fa in un attimo.
- Aggiorniamo .NET Framework a una versione non inferiore a 4.5. Il sistema operativo deve essere almeno Windows 7 SP1/2008 R2. La versione attuale può essere scaricata , leggere informazioni aggiuntive .
- e installare Windows Management Framework 5.1
- Riavviare la macchina.
I diligenti possono eseguire manualmente i passaggi descritti sopra, i pigri - tramite SCCM, politiche, script e altri strumenti di automazione.
La versione attuale di PowerShell può essere scoperta dalla variabile $PSVersionTable. Dopo l'aggiornamento dovrebbe essere all'incirca così:
Ora, utilizzando i cmdlet Get-ChildItem e simili, invece del consueto Path utilizzeremo 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 si può utilizzare questa funzione:
Function ConvertTo-LiteralPath
Param([parameter(Mandatory=$true, Position=0)][String]$Path)
If ($Path.Substring(0,2) -eq "") {Return ("?UNC" + $Path.Remove(0,1))}
Else {Return "?$Path"}
}
Si prega di notare che, imposto il parametro LiteralPath non è possibile utilizzare caratteri jolly (*, ? ecc.).
Oltre al parametro LiteralPath, nella versione aggiornata di PowerShell, il cmdlet Get-ChildItem ha ricevuto il parametro Depth, tramite il quale è possibile specificare la profondità di annidamento per la ricerca ricorsiva; l'ho usato un paio di volte e sono rimasto soddisfatto.
Ora non c'è più motivo di temere che il tuo script PS si perda in un lungo e arduo viaggio e non riesca a vedere file distanti. Ad esempio, questo approccio mi è stato molto utile nella scrittura di uno script per rimuovere l'attributo «temporaneo» dai file nelle cartelle DFSR. Ma questa è un'altra storia, che cercherò di raccontare 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 è attuale per voi?
Sì
Era attuale, ma ho già risolto
Dà fastidio, ma non molto
Non ci ho pensato, sembra tutto funzionare
No
Altro (specifica nei commenti)
155 utenti hanno votato. 25 utenti si sono astenuti.
Fonte: habr.com
