Sfondo (saltare fino in fondo, se si desidera che la domanda)AnkhSVN rompe autorizzazioni di condivisione ASP.NET con SVN 1,7
Recentemente ho aggiornato un repository SVN (ospitato su assembla) a SVN 1.7. Dopo averlo fatto, abbiamo iniziato a riscontrare in modo intermittente molti errori File Access Denied nelle pagine del sito ASP.NET che si trovano nella copia di lavoro locale del repository.
Alcune cartelle hanno anche iniziato a ottenere autorizzazioni di file strani (sono state contrassegnate come di sola lettura) e la condivisione degli utenti è stata rimossa da esse. Questi problemi inizieranno solo a verificarsi dopo un ciclo di aggiornamento/commit, tramite il plugin Visual Studio di AnkhSVN, ma non sempre; sembrava molto capriccioso.
L'unico temp-fix che abbiamo trovato finora è quello di commettere eventuali modifiche in sospeso, eliminare la copia locale e ricontrollare una copia di lavoro completa (con TortoiseSVN). Tuttavia, questa non è una soluzione valida e ha gravi ripercussioni sulla produttività.
Questo sito è un ASP.NET WebWorkerRole basato su Azure. Non ha mai dato problemi prima dell'aggiornamento a SVN 1.7. Ho provato a giocherellare con i permessi interni di IIS per aggirare il problema, tuttavia, nessun dado.
mio ambiente
- Visual Studio 2010 Ultimate SP1 10.0.40219.1
- AnkhSVN 2.3.10509 (ultima versione, supporta SVN 1.7.1)
- TortoiseSVN 1.7.1, Build 22161 - 64 Bit
- funzionando in modalità debug attraverso l'ambiente emulatore Azure
La domanda
E 'possibile che SVN 1.7 o uno qualsiasi degli strumenti nel mio ambiente interrompa le autorizzazioni di file in modo che i file diventino inutilizzabili in un sito ASP.NET? e ancora più importante, come posso risolvere questo?
L'esatto errore di autorizzazione file di pratiche di dumping su è questo:
Accesso al percorso '// // del file' è negato.
Descrizione: si è verificata un'eccezione non gestita durante l'esecuzione di la richiesta Web corrente. Si prega di rivedere lo stack trace per ulteriori informazioni sull'errore e dove è stato originato nel codice.
Dettagli eccezione: System.UnauthorizedAccessException: accesso al percorso '// file //' negato.
ASP.NET non è autorizzato ad accedere alla risorsa richiesta. Considerare concedere i diritti di accesso alla risorsa all'identità di richiesta ASP.NET . ASP.NET ha un'identità di processo di base (in genere {MACHINE} \ ASPNET su IIS 5 o Servizio di rete su IIS 6 e IIS 7 e l'identità del pool di applicazioni configurato su IIS 7.5) che viene utilizzata se l'applicazione non sta impersonando .Se l'applicazione è impersonando tramite, l'identità sarà l'utente anonimo (in genere IUSR_MACHINENAME) o l'utente di richiesta autenticato .
Per concedere l'accesso ASP.NET a un file, fare clic con il tasto destro del mouse sul file in Explorer, scegliere "Proprietà" e selezionare la scheda Sicurezza. Fai clic su "Aggiungi" per aggiungere l'utente o il gruppo appropriato. Evidenziare l'account ASP.NET e selezionare le caselle per l'accesso desiderato.
Ma una copia di lavoro pulita non genererà questo errore. Confrontando i permessi dei due, sembra che le copie funzionanti che non sono buggite siano condivise (con IUSR e l'account locale), mentre quelle rotte hanno zero condivisione, eppure la condivisione non viene mai modificata dall'utente.
È possibile indicare in che modo le autorizzazioni per i file sono state interrotte? A cosa sono assegnati, cosa manca, ecc? Puoi indicare cosa è la radice di copia di lavoro (la cartella contenente la cartella .svn)? Inoltre, penso che sia necessario modificare la domanda per definire la differenza tra repository e copia di lavoro. Non clonare un "repository lato client" in Subversion. –
@SanderRijken: ok, lo aggiornerò. in termini di pensiero del clone, era una cosa di GIT ... – Necrolis