2009-08-31 8 views

risposta

8

Da quello che so non è facilmente possibile. Mentre è possibile utilizzare la soluzione alternativa per gli stream indicati da phoenix, non è possibile gestire i nomi dei file. Internamente ogni classe che lavora con i nomi dei file esegue controlli per nomi di file lunghi.

È possibile creare un'istanza di FileInfo e compilare memebers privati ​​utilizzando la reflection (tuttavia non è consigliabile) e ottenere FileInfo che punta al file con un percorso lungo. Ma quando si tenta di utilizzare questo oggetto, si riceveranno comunque eccezioni PathTooLongException, perché ad esempio, la classe Path (utilizzata pesantemente da FileInfo) controlla il percorso lungo su ogni chiamata di metodo.

Quindi, c'è solo un modo giusto per ottenere un supporto per il percorso lungo senza problemi - implementare il proprio insieme di classi che imiteranno il comportamento di FileInfo. Non è molto complesso (forse solo sicurezza), ma richiede molto tempo.

Aggiornamento: Qui anche due soluzioni pronte per questo problema: AlpfaFS e Zeta Long Paths

+0

+1; il collegamento Zeta Long Paths mi ha dato esattamente quello di cui avevo bisogno. La chiamata API 'FindFirstFile' è l'elemento chiave per replicare' FileInfo'. –

+0

AlphaFS ha fatto il trucco per me. grazie – bjoern

7

qui al lavoro abbiamo a che fare con percorsi lunghi abbastanza frequentemente, e abbiamo dovuto quindi di rotolare in fondo la nostra System.IO per farlo . Beh, non proprio, ma abbiamo riscritto File, Directory, FileInfo, DirectoryInfo e Path solo per citarne alcuni. La premessa di base è che è tutto possibile da una prospettiva API Win32, quindi tutto ciò che devi veramente fare alla fine della giornata è invocare le versioni Unicode delle funzioni API Win32, e quindi sei a posto. È un sacco di lavoro, e può essere un rompicoglioni, a volte, ma non c'è davvero un modo migliore per farlo.

+0

come appaiono le nuove classi, sono scritte a mano al 100% o si sottoclasse la classe File incorporata nella classe File? –

+3

Bene, File è in realtà una classe statica quindi non puoi ereditarla, ma la maggior parte delle classi che potresti pensare alla sottoclasse (FileInfo, DirectoryInfo) sono sigillate, quindi non puoi creare una sottoclasse. Li abbiamo scritti tutti da zero. Non mentirò, abbiamo usato Reflector ALOT :) – BFree

+0

Doh, sì, statico :) Bella, bella risposta. –

0

c'è una grande libreria su Microsoft TechNet per superare il problema a lungo i nomi dei file, si chiama Delimon.Win32.I​O Library (V4.0) ed ha le proprie versioni dei metodi principali da System.IO

Ad esempio, è necessario sostituire:

System.IO.Directory.GetFiles 

con

Delimon.Win32.IO.Directory.GetFiles 

che vi permetterà di h andle file e cartelle lunghi.

Dal sito web:

Delimon.Win32.IO sostituisce le funzioni di file di base di System.IO e supporti file & I nomi delle cartelle fino a un massimo di 32.767 caratteri.

Questa libreria è scritta su .NET Framework 4.0 e può essere utilizzata sia su sistemi x86 & x64. File & Limitazioni della cartella dello standard Lo spazio dei nomi System.IO può funzionare con file con 260 caratteri in un nome file e 240 caratteri in un nome di cartella (MAX_PATH è in genere configurato come 260 caratteri).In genere si verifica l'errore System.IO.PathTooLongException con la libreria .NET standard.

1

Avevo solo bisogno di usare la proprietà FullName ma ricevevo anche PathTooLongException.

utilizzando la riflessione per estrarre il valore FullPath era sufficiente a risolvere il mio problema:

private static string GetFullPath(FileInfo src) 
{ 
    return (string)src.GetType() 
     .GetField("FullPath", BindingFlags.Instance|BindingFlags.NonPublic) 
     .GetValue(src); 
} 
Problemi correlati