"L'accesso al percorso è negato." quando si tenta di archiviare i file su TFS

, ho improvvisamente iniziato a riscontrare un errore simile a "E: \ Websites \ Stage \ mywebsite \ somefile.ascx: l'accesso al percorso è negato" su una moltitudine di file locali quando tentando di controllarli. I file su cui ha esito negativo sono tutti i tipi di file, PNG, ASPX, CONFIG, ecc."L'accesso al percorso è negato." quando si tenta di archiviare i file su TFS

Utilizzo Visual Studio 2013 per Web (aggiornamento 4) e visualstudioonline.com TFS.

I file sono memorizzati in un percorso di rete e ho un'unità mappata a quella posizione. Posso aprire, manipolare e salvare manualmente qualsiasi file con questo errore, quindi non credo che sia veramente un problema di permessi.

Questa configurazione ha funzionato per mesi ma improvvisamente mi sta dando problemi.

Ho eseguito uno script PowerShell nella cartella Get-ChildItem -Include *.* -Recurse -Path 'E:\Websites\Stage' | select fullname,isreadonly e tutti i file restituiscono 'False' sotto la colonna . Nessun errore viene restituito.

Ho bisogno di ulteriori idee.

fonte

2015-01-08 eat-sleep-code

Potrebbe aver funzionato per mesi ma non è supportato ... –

Ho trovato una soluzione alternativa in un altro StackOverflow question.

In sostanza, si accantonano le modifiche in sospeso, quindi si esegue il commit. Non c'è bisogno di sgomberarli.

Suggerisco solo di utilizzarlo per effettuare il check-in delle modifiche finché non si imposta un altro spazio di lavoro localmente (o qualcuno risolve il problema).

Come molti altri, l'utilizzo di Visual Studio 2013 da una VM con un'area di lavoro locale sul computer host mappata tramite un'unità condivisa funzionava bene prima dell'aggiornamento a "VS2013 update 4".

Questa configurazione mi è stata suggerita con il ragionamento che se la VM si blocca, allora non perderei le mie modifiche.

fonte

2015-05-08 19:02:40 Francis

Stranamente, questo "scaffale prima del check-in" risolve il problema. –

Difficile capire perché, ma ha funzionato – reckface

Sfruttare un bug nel software come soluzione temporanea non elimina il rischio dell'attività. Questo non è un modello supportato. Utilizzare una posizione disco locale. –

La memorizzazione dello spazio di lavoro locale in un percorso di rete non è supportata e non dovrebbe mai essere eseguita.

Avere uno spazio di lavoro "locale" (sul proprio computer locale) in cui si modificano i file e si esegue il check-in. Quindi disporre di una build automatizzata che pubblica i file in una posizione di propria scelta.

fonte

2015-01-08 13:57:21

sigh. Questo è il motivo per cui i prodotti Microsoft succhiano così tanto. In git, un percorso di rete è solo un'altra posizione, come dovrebbe essere –

Controllo sorgente basato su server, wither TFVC, Subversion o Perforce, non è Git e non viene eseguito come Git. Microsoft supporta Git in TFS molto bene. Non dare la colpa al venditore per le tue scelte. –

Ho eseguito Windows/Visual Studio in Parallels su un Mac e ho salvato un progetto sul desktop (sì, vergognimi). Internamente questo percorso è gestito come \\ psf \ Home \ Desktop anche se è memorizzato localmente e non nella rete. Resta comunque la stessa eccezione e viene risolto spostandolo sul tuo disco fisso (c: \ ...)

fonte

2015-05-22 08:15:30 Brandtware

Che è ancora un percorso condiviso, che non è supportato. Gli spazi di lavoro dovrebbero essere unici sia per un Maher che per l'utente. Poiché sembra una posizione condivisa, causa lo stesso errore. –

Un'altra soluzione: http: // StackOverflow.it/a/41601755/802791 –

"L'accesso al percorso è negato." quando si tenta di archiviare i file su TFS

risposta

Problemi correlati