Doe even een om erachter te komen welk proces het bestand open heeft.

Dit soort files wordt gebruikt door updateservices die programma's zelf hebben ipv Windows Update te gebruiken, bijvoorbeeld
van Google Chrome, Microsoft Edge, Adobe Reader enz enz.
Die willen uiteraard voorkomen dat terwijl de service bezig is automatisch een update te downloaden en installeren jij
als gebruiker met een functie "naar updates zoeken" in de applicatie zelf ook weer een update start.

Als nou het updaten niet lukt omdat het bijvoorbeeld niet lukt de boel te downloaden (als je ziet wat sommige mensen hier
allemaal aan hun PC verbouwen omdat ze de boel onder controle willen houden...) dan kan die situatie, die normaal maar
een minuutje duurt, permanent blijven bestaan.

Ga maar eens in je "services" en in je "task scheduler" kijken wat er allemaal op dit gebied draait...

Ik denk niet dat de poster beschikt over Cygwin integratie en een live cd van Unix achtig OS gaat ook niet in dit scenario sinds de data dan niet live draait en je hooguit het bestand kan verwijderen maar niet zien wat het doet.


\Users\All Users is symbolic link naar \ProgramData je zult daar dan ook eerst moeten kijken.
Als eerste start op in veilige modus
Zet weergave van bestand extenties aan zoek op extentie wat het zou moeten zijn en of dit betrouwbaar lijkt.
Daarna check security/beveiliging op wie de owner is wie de rechten inherit.
Check de details, aanmaak datum, modificatie datum.

Vertrouw je het niet dan upload het naar bijvoorbeeld virustotal voor een second file opinion.
Hierna kun je ook nog een tool als Sysinternals Process Explorer gebruiken om te zien of er iets actief gebruikt wordt wat verwijst naar het zogenaamde lock bestand. hxxps://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

Dat gezegd heb ik nog nooit van deze bestandsnaam gehoord of gezien in enige Windows omgeving kan dus ook iets zijn van een programma wat je op je OS hebt staan vanuit fabriek of er zelf opgezet.

Oh, wacht! Sorry, dat commando heeft Windows natuurlijk niet. Er is wel iets van 'sysinternals' zie ik (whatever that may be) met enigszins vergelijkbare functionaliteit. Het Handle tool: https://docs.microsoft.com/en-us/sysinternals/downloads/handle. Daarmee kan je zien of er processen zijn die dat bestand geopend hebben.

Heb je onlangs nieuwe software geïnstalleerd op al je pc's die het kan verklaren? Als je dat niet zo kan bedenken is het inderdaad handig om zichtbaar te maken welk proces die bestanden eigenlijk in gebruik heeft. Als je wel een idee hebt zou het stoppen van dat proces het bestand moeten doen verdwijnen, om het weer te laten verschijnen als het start.

Waar de naam en het ontbreken van inhoud (0 bytes) op lijken te duiden is dat dit zogenaamde lock-files zijn. Als programma's ergens iets wijzigen, bijvoorbeeld in een bestand, in een database, in de registry, het kan van alles zijn, kan dat in het honderd lopen als hetzelfde programma twee keer gestart wordt en vrolijk aan het wijzigen slaat terwijl er al een exemplaar van het programma actief is. Om daar ongelukken mee te voorkomen is er iets nodig dat ofwel dubbele toegang volledig blokkeert, ofwel dat een signaal oplevert waaraan het programma kan zien dat het al actief is en dus niet aan de slag kan met de wijzigingen. Een (op zich vrij primitieve) manier om dat te doen is om een bestandje aan te maken als het wijzigingsproces begint en weer te verwijderen als het klaar is.

Dit lijken zulke bestandjes te zijn, en de vraag is dan bij welk proces ze horen. Als je dat weet te achterhalen is het vermoedelijk opeens best logisch dat het zoiets nodig heeft.

Bij mij staat er een exemplaar in C:\ProgramData (a.k.a. C:\Users\All Users) en een in C:\ProgramData\Mozilla.. Dit bestand heeft te maken met het installeren/updaten van Mozilla software (Firefox, Thunderbird, etc.). Dit betekent ook dat het niet in C:\ProgramData thuishoort. Gewoon verwijderen.

Je hebt in je zoektocht toch wel het concept file locking kunnen vinden ?

Gezien de naam, en de 0 bytes zal het een lock file zijn , zoals al gezegd is.

De xxxxx zijn waarschijnlijk getallen . Misschien random, misschien het proces-id .

Als programma zijn er soms dingen waarvan er maar één tegelijk moet gebeuren .
Terwijl het programma wel multi-threaded is (of gewoon vaker opgestart kan worden ) .

Je kunt je voorstellen dat twee Excellen die dezelfde spreadsheet tegelijk updaten een groot probleem zijn.
Ook software die updates van zichzelf binnenhaalt en installeert - dat moet niet tegelijkertijd .

Daarvoor heb je het concept 'locking' - Excel en anderen maken een lock file om aan te geven dat ze een bepaald bestand open hebben.
En gezien de naam zal dit een file zijn van een programma dat daarmee - aan zichzelf - aangeeft 'ik ben al bezig met een update' .

Normaal gesproken worden lock files weer weggehaald als het programma (netjes) afsluit . Als een programma crashed of hard afgesloten wordt zijn de lock files niet weg .
(Dat zijn op kantoor dus wel eens dingen bij spreadsheets en documenten op een fileshare - iemand opent 'm , trekt z'n laptop uit het docking station, and dan blijft dat bestand gelocked staan.)

En soms is het een software bugje dat een lock file niet opgeruimd wordt.

Goede kans dat er nadat je kijkt - en zeker na een reboot - geen enkel proces is meer is dat die file open heeft .

https://en.wikipedia.org/wiki/File_locking

Ja, sorry, ik had het ondertussen ook al gezien (te haastig gereageerd, het pad met die forward slashes in de vraag van Anoniem heeft me op het verkeerde been gezet).

Hier de topic starter.

Ik heb de slashes inderdaad verkeerd gezet. Het gaat om de map Users\All Users\ .
De xxxxx... vervangt een code (zo te zien hexadecimaal). Op mijn verschillende PC's is die code allemaal hetzelfde, en de file heeft als datum 12 of 13 augustus.
Volgens REVO heb ik vlak voor die datum/tijd een VC++ update gedaan (via Patch my PC). Ook is kort voor die datum/tijd Windows geupdated, maar dan zouden meer mensen die file moeten kunnen zien.

Als ik die file re-name (dan lijkt ie dus weg), wordt ie daarna opnieuw aangemaakt met de aktuele datum.

Groeten

Ok - aangezien de file opnieuw aangemaakt wordt als je 'm weghaalt/renamed zal er een actief proces zijn dat deze file wil hebben.

zo te zien kun je het proces dat deze file gebruikt vinden op deze manier :

https://helpcenter.gsx.com/hc/en-us/articles/115015880627-How-to-Identify-which-Windows-Process-is-Locking-a-File-or-Folder

Schakel alle niet microsoft opstart items, services uit via msconfig en services.msc of in win10 via opstart items in de taakbeheer.
Start dan in veilige modus zonder netwerk mogelijheid en verwijder of hernoem het bestand.

Herstart weer in normale modus en kijk of het terug is.
Zo nee dan goed en kun je 1 voor 1 je services of in batches weer aanzetten. heb je het item gevonden of een batch waar het gebeurd dan kun je of het item in combo met lockfile opzoeken mogelijk. Of in geval van de batch moet je het elemination process nog even voortzetten.
Doe dit tot je alle lockfiles in kaart hebt en daarna kun je kijken waarom het gebeurt.

Gebeurd het ook met alle non Microsoft opstart services uit dan moeten we nog even verder zoeken.

Natuurlijk vindt een gebruiker van Microsoft software het normaal dat je bij het gebruik van een programma om een databestand aan te passen (spreadsheet in dit geval) lock files zou krijgen in een systeemdirectory die helemaal niet toegankelijk zou moeten zijn voor gebruikers. Zoiets heet spaghetti toegang.

Locking semaphores signals is de basis voor informatietechnologie. Leer eens wat meer van E.Dijkstra.
Als je daar geen rekening mee houdt dan heb je een onbetrouwbare niet voorspelbare omgeving.

En natuurlijk heb je degenen die de klok hebben horen luiden maar niet weten waar de klepel hangt. Het gaat helemaal niet over het op zich geldige en zinvolle (file) locking, het gaat over het plaatsen van (lock) bestanden op plaatsen waar deze niet thuishoren.

https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

als het bestand meteen terugkomt dan zou ik zeggen kijk via dit systernals progamma welk process dit doet

Hier de topic starter weer.

Het ziet er naar uit dat Thunderbird versie 91.03 de oorzaak is voor die UpdalteLock-file.
Als ik de UpdateLock-file verwijderd heb, wordt op het tijdstip dat ik Thunderbird 91.03 opstart die UpdateLock-file weer aangemaakt. Als ik dan met Thunderbird open, die UpdateLock-file wil verwijderen, krijg ik een error-melding.

Dat is dus wel duidelijk.

Nu nog de vraag: waarom doet Thunderbird 91.03 dit?

Het zou wel fijn zijn geweest als die UpdateLock-file i.p.v. geen inhoud (0 bytes) een tekst had bevat van wie die Lock afkomstig is en waarom ie er is.
Ik raak van dit soort mysterieuze PC-zaken heel erg achterdochtig en in de stress.

Groeten

Hier de topic starter.
U hebt gelijk, ik heb die nu ook gevonden voor Firefox.

Voor Thunderbird staat ie in Users\All Users\ .

Is dus een Mozilla-aktie.

Vraag me af wat hier nu de bedoeling van is?
Via een internet-search is bij Mozilla over UpdateLock niets te vinden. Zoals ik in mijn vorige reaktie al schreef, ik hou niet zo van die mysterieuze zaken.

Groeten


Groeten

Dat is je hierboven toch al uitgelegd in o.a. de 2e en 5e reactie? Lees dat nog eens terug zou ik zeggen!