De gevraagde bewerking kan niet worden uitgevoerd op een bestand met een door de gebruiker toegewezen sectie open

Telkens wanneer ik 4 bestanden naar mijn bin-map probeerde te kopiëren, krijg ik na het stoppen van de hoofdservice een foutmelding met één bestand (TexteDll). De fout is:

Cannot copy TexteDll: The requested operation cannot be performed on a file 
with a user-mapped section open

Het kan te wijten zijn aan een systeemvergrendeling. Of misschien gebruikt een ander proces deze DLL. Toen ik googelde, ontdekte ik dat het opnieuw opstarten van het systeem dit zou kunnen oplossen.

Kan iemand hier een oorzaak of oplossing voor bedenken? Ik heb de eigenschappen van TexteDll geïnspecteerd (algemeen, versie, beveiliging, enz.). Alles lijkt normaal.

Antwoord 1, autoriteit 100%

In mijn geval was het de Verkenner die de DLL vergrendelde die was gecompileerd in de map Debug… Vreemd, niet?

Ik kwam erachter met een tool genaamd Unlocker.

Moest verwijderen met Unlocker, zelfs toen het zei dat het bestand niet vergrendeld was, en ik kon de map niet verwijderen totdat ik dat ene bestand niet had verwijderd…

Daarna is het gecompileerd.

BEWERKEN:

Ik ben erachter waarom dit in mijn geval gebeurde. Ik had de DLL geopend in een teksteditor in Visual Studio…

Antwoord 2, autoriteit 39%

• Soms wanneer u dubbelklikt op een waarschuwing over de verwijzing naar
  assemblageversie komt niet overeen tussen twee of meer projecten die u vergeet te doen
  sluit het montagevenster en het blijft daar onder andere
  tabs… zodat je eindigt met de assembly die wordt vergrendeld door VS
  zelf en het kostte me behoorlijk wat tijd om dat uit te zoeken 🙂

  Wees voorzichtig met de kracht die VS biedt 😉

• Nog een nepscenario. Soms gewoon het hele obj verwijderen
  map of alleen het bestand dat is gewaarschuwd, omdat de vergrendelde hierbij helpt
  waardeloze fout.

Antwoord 3, autoriteit 20%

Sluit alle documenten op VS en probeer opnieuw op te bouwen. Als het niet werkt, herstart VS. Dit probleem houdt verband met het vergrendelen van DLL-bestanden.

Antwoord 4, autoriteit 7%

Sluit visual studio, verwijder bin , debug release map en start visual studio project opnieuw.
dat loste mijn probleem op

Antwoord 5, autoriteit 6%

Ik had hetzelfde probleem. Hoe ik het heb opgelost was:

1. Open “Taakbeheer”
2. Taak “Explorer.exe” beëindigen
3. Klik op “Bestand” –> Nieuwe taak maken — Typ “explorer.exe” –> Oké
4. Maak mijn project schoon en het werkt

Antwoord 6, autoriteit 6%

Ik ben een ontwikkelaar en hou niet van apps die in Registery worden geïnjecteerd zoals Unlocker.
Ik heb SysInternals Process Explorergebruikt, welk proces mijn dll Find > Find Handle or Dll [Ctrl-F]en schakelde het proces uit.

Antwoord 7, autoriteit 5%

Ik had hetzelfde probleem en in mijn geval bleek dat het bestaande uitvoerbestand was vergrendeld door een andere toepassing.

U kunt controleren welke toepassing uw uitvoerbestand vergrendelt met OpenedFilesView:
http://www.nirsoft.net/utils/opened_files_view.html

Antwoord 8, autoriteit 5%

Anderen hebben al vastgesteld dat deze fout te wijten is aan een andere toepassing die het bestand vergrendeld heeft. Ik wilde er alleen op wijzen dat git diffook bestanden vergrendelt totdat je ermee stopt. Dat is wat dit in mijn geval veroorzaakte.

Antwoord 9, autoriteit 3%

Gebruikt u antivirussoftware? Het is mogelijk dat de AV-software (of een ander stuk software) het bestand aan het lezen was met behulp van de API’s voor bestandstoewijzing die het probleem hebben veroorzaakt.

Antwoord 10, autoriteit 3%

In mijn geval moest ik een hangende MSBuild.exeProces doden die het bestand vergrendelt (het was er zelfs nadat ik Visual Studio heb gesloten).

Antwoord 11, Autoriteit 3%

Het is gewezen in 2016 door Andrew Cuthbert dat git diffook bestanden vergrendelt totdat u eruit stopt.

Dat zal niet het geval zijn met GIT 2.23 (Q3 2019).

Zie commit 3Aef54e (11 jul 2019) door Johannes Schindelin (dscho) .
^{(samengevoegd door junio c hamano – gitster– in commit d9beb46 , 25 jul 2019)}

diff: munmap()Bestandsinhoud Voordat u externe diff werkt

Bij het uitvoeren van een externe diff uit, zeg, een diff tool, het is veilig voor
aannemen dat we de betreffende bestanden willen schrijven.
Op Windows betekent dat dat er geen ander proces kan zijn met een open handgreep aan
zei bestanden, of zelfs slechts een toegewezen regio.

Dus laten we ervoor zorgen dat git diffzelf geen open handgreep hield aan de betreffende bestanden.

In feite zullen we het bestandspaar meteen vrijgeven, omdat de externe diff de bestanden gebruikt die we net hebben geschreven, dus we hoeven niet meer de inhoud van het bestand in het geheugen te houden.

Deze fixes git-for-windows # 1315

Loopt “git diff“^(man)terwijl externe diff in een staat met niet-samengevoegde paden die worden gebruikt voor segfault, wat is gecorrigeerd met Git 2.30 (Q1 2021).

Zie commit d668518, commit 2469593(06 nov 2020) door Jinoh Kang (iamahuman).
^{(Samengevoegd door Junio C Hamano — gitster—in commit d5e3532, 21 nov 2020)}

diff: toestaan NULLnaar diff_free_filespec_data()

^{Uitgeschreven door: Jinoh Kang
Uitgeschreven door: Junio C Hamano}

Bevestig 3aef54e8b8(“diff: munmap()bestandsinhoud voordat externe diff werd uitgevoerd”, introduceerde Git v2.22.1) aanroepen naar diff_free_filespec_datain run_external_diff,die NULL-aanwijzers.

Los dit op en voorkom dergelijke bugs in de toekomst door van diff_free_filespec_data(NULL)een no-op te maken.

Fixes: 3aef54e8b8(“diff: munmap() bestandsinhoud voordat externe verschil”)

Antwoord 12, autoriteit 2%

Geen van de hier geposte oplossingen werkte voor mij. Het was devenv.exe (Visual Studio) die het bestand vergrendelde, maar als ik het opnieuw zou opstarten, zou het het opnieuw vergrendelen.

Bizar genoeg stond Windows me niet toe de bestanden te verwijderen (naar de Prullenbak), maar Shift+Delete (permanent verwijderen) werkte.

Antwoord 13, autoriteit 2%

Het verwijderen van de obj-map en het opnieuw opbouwen werkte voor mij

Antwoord 14, autoriteit 2%

Ik had hetzelfde probleem. Opnieuw opstarten werkte bij mij niet. Er was een proces genaamd VBSCompiler werd uitgevoerd in taakbeheer. Ik moest het proces beëindigen om deze fout te herstellen.

Antwoord 15

Sluit Visual Studio en voer het uit als beheerder. Het heeft mijn probleem opgelost.

Antwoord 16

De oplossing voor mij was om alle instanties van VS te sluiten en alle hangende devenv.exe-processen te beëindigen.

Antwoord 17

Ik zag deze fouten bij het bouwen van Dot Net-applicaties met Ant.

In mijn geval was het onze bedrijfsback-upsoftware, de Symantec DLO Agent. Het stoppen en de map in mijn antivirussoftware uitsluiten en Visual Studio sluiten lijkt te werken.

Antwoord 18

in mijn geval de obj-map in de projectroot verwijderd en het project opnieuw opbouwen loste mijn probleem op!!!

Antwoord 19

Ik kwam deze fout tegen en het bleek dat het probleem was dat FxCop tegen mijn project liep. Ik sloot FxCop af en toen kon ik weer compileren.

Antwoord 20

Als het een webtoepassing is, kan het verwijderen van bestanden in de map Tijdelijke ASP.NET-bestanden een oplossing zijn.

Antwoord 21

Als u profilers zoals AQ-tijd gebruikt, kunnen deze ook het bestand vergrendelen. De oplossing in dit geval zou zijn om de profiler opnieuw te starten of de montage van de profiler eenvoudigweg te lossen / te laden / te laden.
Voor AQ-tijd merkte ik dat het na enige tijd het bestand vrijgeeft, maar ik kan niet voor het leven van mij vertellen wat die time-out is.
Lijkt willekeurig

Antwoord 22

Geen van de bovenstaande opgelost dit probleem.

Iemand had één project in mijn oplossing ingesteld om X64 CPU te gebruiken in de bouwconfiguratie. Het veranderen in elke CPU zorgde ervoor dat de build een nieuwe map gebruikt. Ik weet nog steeds niet welk proces (heeft) een slot in dat bestand.

Antwoord 23

is er met mij gebeurd nadat ik het Project Target CPU van ‘Any CPU‘ ‘<X64‘ en vervolgens terug naar ‘Any CPU‘.

Los het op door de map Objte verwijderen (voor beginners: maak je geen zorgen over het verwijderen van de obj-map, het zal opnieuw worden opnieuw gemaakt in de volgende compilatie).

Antwoord 24

Dit is een andere. Het lijkt erop dat het kan gebeuren als gevolg van een bestandshendel dat in gebruik is. Dit is de reden waarom dit antwoord werkt, ik geloof. Voor mij had ik het more project.csprojvan de opdrachtregel en vergeten had ik het opengelaten. Dus het handvat was vergrendeld voor het lezen.
SysInternals heeft een Neat Command Line-tool genaamd handleals u gedeeltelijk bent aan de opdrachtregel. U kunt handle <partial name of whatever file or folder you want>en het zal u vertellen welk programma (indien aanwezig) het gebruikt.

handvat door sysinternalen

Antwoord 25

In mijn geval was het probleem met visuele micro op Visual Studio 2019. Het klagen over de \_vm\compile.vmps.xmlbestand. Kan het misschien niet verwijderen / wijzigen. Ik heb dit probleem opgelost door de map _vmin de hoofdmap van het project te verwijderen en de oplossing opnieuw op te bouwen.

Antwoord 26

In mijn geval probeerde ik API aan mijn lokale IIS te publiceren, ik heb het opgelost door eenvoudig het veroorzakende bestand in de IIS-doelmap te verwijderen en de API opnieuw publiceert, het leek erop dat het beschadigd is of iets.

Antwoord 27

Mijn probleem is ook opgelost door door de procesverkenner te diften. Het proces dat ik moest doden was de MySQL Notifier.exe die nog steeds draaide na het sluiten van alle VS- en SQL-applicaties.