"Il formato del percorso specificato non è supportato."

Ho il seguente codice nel mio servizio web:

string str_uploadpath = Server.MapPath("/UploadBucket/Raw/");
FileStream objfilestream = new FileStream(str_uploadpath +
                fileName, FileMode.Create, FileAccess.ReadWrite);

Qualcuno può aiutarmi a risolvere il problema con questo messaggio di errore dalla riga 2 del codice.

Il formato del percorso specificato non è supportato.

L'autorizzazione per la cartella è impostata per l'accesso completo a tutti ed è il percorso effettivo della cartella.

Il punto di interruzione mi ha dato il valore di str_uploadpathcome C:\\webprojects\\webservices\\UploadBucket\\Raw\\.

Cosa c'è di sbagliato in questa stringa?

Invece di usare str_uploadpath + fileName, prova a usare System.IO.Path.Combineinvece:

Path.Combine(str_uploadpath, fileName);

che restituisce una stringa.

Vedo che l'originatore ha scoperto che l'errore si è verificato durante il tentativo di salvare il nome del file con un intero percorso. In realtà è sufficiente avere un ":"nel nome del file per ottenere questo errore. Se ":"il nome del file potrebbe essere presente (ad esempio, se nel nome del file è presente un timbro della data) assicurati di sostituirli con qualcos'altro. Vale a dire:

string fullFileName = fileName.Split('.')[0] + "(" + DateTime.Now.ToString().Replace(':', '-') + ")." + fileName.Split('.')[1];

Per me il problema era un carattere di inclusione da "‪" sinistra a destra invisibile all'occhio umano .
Si è bloccato all'inizio della stringa (appena prima della "D"), dopo aver copiato e incollato il percorso, dalla scheda di sicurezza delle proprietà del file di Windows.

var yourJson = System.IO.File.ReadAllText(@"D:\test\json.txt"); // Works
var yourJson = System.IO.File.ReadAllText(@"‪D:\test\json.txt"); // Error

Quindi quelle, identiche a prima vista, due linee sono in realtà diverse.

Se stai tentando di salvare un file nel file system. Path.Combine non è a prova di proiettile in quanto non ti aiuterà se il nome del file contiene caratteri non validi. Ecco un metodo di estensione che rimuove i caratteri non validi dai nomi dei file:

public static string ToSafeFileName(this string s)
{
        return s
            .Replace("\\", "")
            .Replace("/", "")
            .Replace("\"", "")
            .Replace("*", "")
            .Replace(":", "")
            .Replace("?", "")
            .Replace("<", "")
            .Replace(">", "")
            .Replace("|", "");
    }

E l'utilizzo può essere:

Path.Combine(str_uploadpath, fileName.ToSafeFileName());

Tra le altre cose che possono causare questo errore:

Non è possibile avere determinati caratteri nella stringa PathFile completa.

Ad esempio, questi caratteri manderanno in crash la funzione StreamWriter:

"/"  
":"

potrebbero esserci altri caratteri speciali che lo mandano in crash. Ho scoperto che questo accade quando provi, ad esempio, a inserire un timbro DateTime in un nome di file:

AppPath = Path.GetDirectoryName(giFileNames(0))  
' AppPath is a valid path from system. (This was easy in VB6, just AppPath = App.Path & "\")
' AppPath must have "\" char at the end...

DateTime = DateAndTime.Now.ToString ' fails StreamWriter... has ":" characters
FileOut = "Data_Summary_" & DateTime & ".dat"
NewFileOutS = Path.Combine(AppPath, FileOut)
Using sw As StreamWriter = New StreamWriter(NewFileOutS  , True) ' true to append
        sw.WriteLine(NewFileOutS)
        sw.Dispose()
    End Using

Un modo per evitare questo problema è sostituire i caratteri problematici in NewFileOutS con altri benigni:

' clean the File output file string NewFileOutS so StreamWriter will work
 NewFileOutS = NewFileOutS.Replace("/","-") ' replace / with -
 NewFileOutS = NewFileOutS.Replace(":","-") ' replace : with - 

' after cleaning the FileNamePath string NewFileOutS, StreamWriter will not throw an (Unhandled) exception.

Spero che questo salvi a qualcuno qualche mal di testa ...!

Se ricevi questo errore in PowerShell, è molto probabile che tu stia utilizzando Resolve-Pathper risolvere un percorso remoto, ad es

 Resolve-Path \\server\share\path

In questo caso, Resolve-Pathrestituisce un oggetto che, se convertito in una stringa, non restituisce un percorso valido. Restituisce il percorso interno di PowerShell:

> [string](Resolve-Path \\server\share\path)
Microsoft.PowerShell.Core\FileSystem::\\server\share\path

La soluzione è utilizzare la ProviderPathproprietà sull'oggetto restituito da Resolve-Path:

> Resolve-Path \\server\share\path | Select-Object -ExpandProperty PRoviderPath
\\server\share\path
> (Resolve-Path \\server\share\path).ProviderPath
\\server\share\path

Prova a cambiare:

Server.MapPath("/UploadBucket/Raw/")

per

Server.MapPath(@"\UploadBucket\Raw\")

Questo era il mio problema, che potrebbe aiutare qualcun altro, sebbene non fosse un problema dell'OP:

DirectoryInfo diTemp = new DirectoryInfo(strSomePath);
FileStream fsTemp = new FileStream(diTemp.ToString());

Ho determinato il problema inviando il mio percorso a un file di registro e trovandolo non formattato correttamente. Corretto per me era semplicemente:

DirectoryInfo diTemp = new DirectoryInfo(strSomePath);
FileStream fsTemp = new FileStream(diTemp.FullName.ToString());

L'uso del metodo Path.Combine aiuta? È un modo più sicuro per unire insieme i percorsi dei file. Potrebbe essere che abbia problemi a unire i percorsi insieme

Sto usando il (limitato) generatore di espressioni per una variabile da utilizzare in una semplice attività del file system per creare un archivio di un file in SSIS.

Questo è il mio trucco rapido e sporco per rimuovere i due punti per fermare l'errore: @ [User :: LocalFile] + "-" + REPLACE ((DT_STR, 30, 1252) GETDATE (), ":", "-") + ".xml"

Oggi ho avuto lo stesso problema. Il file che stavo cercando di caricare nel mio codice era aperto per la modifica in Excel. Dopo aver chiuso Excel, il codice ha iniziato a funzionare!

Se il valore è un URL di file come file: // C: / qualunque cosa, usa la classe Uri per tradurre in un nome di file normale:

var localPath = (new Uri(urlStylePath)).AbsolutePath

In generale, l'utilizzo dell'API fornita è la migliore pratica.