VS Code has been trying to update for a few days now. It opens the innoupdater, but the updater never works.
Today I force stopped the updater from task manager and now my VS Code is gone (The VS Code icon is gone). It's showing the below error every time I try starting it.
windows cannot access the specified path you may not have permission
The innoupdater is also not working anymore, even if I reinstall. I am not sure How I can get my setting back.
You can safely reinstall vscode. Settings preserved even after uninstall in %USERPROFILE%\.vscode.
Also, you can use vscode built-in sync services or extension
In my old macOS app, written in Objective-C, I am debugging a reproducible problem in which a file package is removed too early during a system frameworks call. To get a clue, I would like to have the debugger break whenever a file is deleted. To that end, I have set symbolic breakpoints in Xcode at these symbols:
unlink
unlinkat
-[NSFileManager removeItemAtPath:error:]
-[NSFileManager removeItemAtURL:error:]
All of these breakpoints resolve as expected to actual breakpoints, and they break as expected when files are deleted as expected. But during the troublesome too-early file deletion, no break occurs.
Are there any other functions in macOS which can delete files, for which I should add breakpoints?
BACKGROUND INFORMATION:
The problem occurs in my custom NSDocument subclass, when calling [super saveDocument] on a newly-duplicated (as in File > Duplicate) but never-before saved document package. Such document packages reside in ~/Library/Autosave Information/, and when things work properly, remain there until the Save panel appears, and is subsesquently dismissed. However, in the bug case, the package disappears immediately when the user clicks File > Save (or an Auto Save occurs), apparently causing a later error indicating that the deleted package could not be moved to the path returned by the Save Panel.
I also tried changing the POSIX permissions of that package after it appears, and before clicking File > Save, to octal 500. The idea is that it could not be deleted, and I also turned on all of my exception and error breakpoints, hoping the mystery deleter would squawk to the debugger console. Result: The package was not deleted, and, as I had hypothesized, the Save operation succeeded. But nothing squawked. So this mystery deleter is indeed the problem, but is apparently both stealthy and forgiving :(
UPDATE 2019-JUL-19:
After 5 days of finding other things to do, I decided to bite the bullet and use DTrace as suggested Ken Thomases. It worked, showing me that all files in the subject file package were deleted by a call to libsystem_kernel.dylib__unlink, which was in turn called by -[NSFileManager removeItemAtPath:error:].
I do not know why my breakpoints on these functions did not break for these calls, except maybe there is a clue at the bottom of the stack trace, mentioning "xpc". Is it possible that this file deletion is done by an XPC helper process? Does DTrace also probe helper processes of the process being probed? That would be pretty amazing.
Here is an abridged DTrace session transcript:
Air2 jk$ sudo dtrace -n 'syscall::unlink*:entry,syscall::rmdir:entry,syscall::rename:entry { printf("time=%d arg=%s\n", timestamp/1000000000, copyinstr(arg0)); ustack(100); }' -p `pgrep MyApp`
Password:
dtrace: description 'syscall::unlink*:entry,syscall::rmdir:entry,syscall::rename:entry ' matched 4 probes
CPU ID FUNCTION:NAME
1 178 unlink:entry time=6562 arg=/Users/jk/Library/Autosave Information/Unsaved MyApp Document.bmco
libsystem_kernel.dylib`__unlink+0xa
libremovefile.dylib`__removefile_tree_walker+0x147
libremovefile.dylib`removefile+0x99
Foundation`-[NSFilesystemItemRemoveOperation main]+0xba
Foundation`__NSOPERATION_IS_INVOKING_MAIN__+0x11
Foundation`-[NSOperation start]+0x2db
Foundation`-[NSFileManager removeItemAtPath:error:]+0x54
AppKit`__90-[NSDocumentController(NSInternal) _autoreopenDocumentsFromRecords:withCompletionHandler:]_block_invoke_2+0x90
AppKit`__89-[NSDocumentController reopenDocumentForURL:withContentsOfURL:display:completionHandler:]_block_invoke_2+0xa6
AppKit`___NSMainRunLoopPerformBlockInModes_block_invoke+0x19
CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__+0xc
CoreFoundation`__CFRunLoopDoBlocks+0x17b
CoreFoundation`__CFRunLoopRun+0xae8
CoreFoundation`CFRunLoopRunSpecific+0x1f3
HIToolbox`RunCurrentEventLoopInMode+0x124
HIToolbox`ReceiveNextEventCommon+0x164
HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter+0x40
AppKit`_DPSNextEvent+0x3de
AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+0x548
ViewBridge`-[NSViewServiceApplication nextEventMatchingMask:untilDate:inMode:dequeue:]+0x5f
AppKit`-[NSApplication run]+0x292
AppKit`NSApplicationMain+0x309
libxpc.dylib`_xpc_objc_main.cold.3+0x38
libxpc.dylib`_xpc_objc_main+0x203
libxpc.dylib`_xpc_copy_xpcservice_dictionary
ViewBridge`xpc_connection_handler
ViewBridge`NSViewServiceApplicationMain+0xbff
com.apple.appkit.xpc.openAndSavePanelService`main+0xc0
libdyld.dylib`start+0x1
com.apple.appkit.xpc.openAndSavePanelService`0x1
(The call in that transcript apparently tried to unlink the file package, which I think would have failed since the package was not empty. It is followed by several similar calls which walk the package tree, deleting each node, and finally a repeat of that call to delete the package, apparently with success.)
UPDATE 2019-AUG-06
Although we now know the low-level cause of the problem, we still don't know the high-level cause. I have since discovered that the problem (premature deletion of the temporary document file in ~/Library/Autosave Information) only occurs in macOS 10.15 Beta 4-5 (the current version) and only when the app is built with App Sandbox OFF. When App Sandbox is on, the relevant Autosave Information is in a different location, in the app's container, so this should be a good clue! The problem is easily reproducible with a small demo app, Core Data, document-based, which I have submitted to Apple along with a short video. If anyone has a line to Apple, please direct their attention to FB6937676 !
A rename operation will make the source path no longer refer to a file (looks like the file at the source path was deleted). It can also unlink/delete a file at the destination path, although it will be replaced with the file at the source path. So, that would be rename(), renameat(), renamex_np(), and renameatx_np().
Of course, rmdir() can remove a directory, but only if it's empty.
Apparently, there's a hidden delete() system call. It's described as "delet[ing] a name from the filesystem using Carbon semantics". It's possible the frameworks are using that.
I am currently using Pyzo and changed its font and background color according to the instructions on their website (http://www.pyzo.org/pyzo_themes.html) by changing the init() in the base.py file. Everything was fine until I wanted to change the settings back to normal. When I try to open any .py file Pyzo gives me the error
"Error loading file: local variable fore1 referenced before assignment".
On closing the error message, the Shell just keeps warming up and nothing happens. On the left side where the editor would have been, there is a small white box with a smaller yellow one inside.
Opening up Pyzo on its own does not give the error, but the same problem with the Shell and editor.
I tried:
changing the settings in base.py manually to their default value
copying the backup file I made before the changes back into the directory
uninstalling Pyzo with IOBit Uninstaller to catch all hidden files and reinstall it (about 10 times already)
I thought reinstalling it would resolve the matter but obviously there must be a different issue here. I really hope someone had the same problem, thanks in advance for any help!
I must be missing something. After downloading AntlrWorks2 I found the executable bin/antlrworks2.exe and bin/antlrworks264.exe. Aren't these supposed to be the standalone version of the tool? Neither works for me; after a NetBeans splash screen, the first times around I got an error message on missing packages; after a couple of times I chose to go on regardless, but now (still after the initial spash screen) there is simply nothing happening at all.
I can't find any tutorial or manual detailing how to run AntlrWorks stand-alone, so any help is much appreciated.
This is due to a bug in the NetBeans platform. I filed a report but it hasn't received a reply yet:
Cannot launch platform application after moving installation folder
Here is a workaround that does not delete any preferences you have customized:
I found that deleting just the var folder under the user's generated
.antlrworks2 settings folder resolves the issue...
Still an issue as of date of this post. Deleting the .antlrworks2 folder from \users\username\AppData\Roaming does work - you can find this folder by putting %APPDATA% into your file explorer address bar (exactly as shown) - that will go to the app data folder for your current user login session. Delete the .antlrworks2 folder and then re-run the app.
When I install my finished product it runs fine until the very last action is done (a button that 'saves' the job).
The program pops this error up:
Unhandled exception has occurred in your application. If you click continue, the app will ignor this error and attempt to continue. If you click quit, the app will close.
Could not find a part of the path 'C:\Program Files (x86)\ATR\Save A Job\obj\Release\42\ATR\BackupProgram\Backup.xml
For some reason, the program is looking for the backup.xml file in the wrong place. (and seemingly added folders)
The way I'm calling the backup.xml file in the program is by:
(System.Environment.SpecialFolder.ProgramFile sX86 & "\ATR\Save A Job\Backup.xml")
Which, could be the wrong way, but it makes sense to me.
I would assume that the full path to the file location would be as follows:
C:\Program Files (x86)\ATR\Save A Job\backup.xml
However, it is looking for it in the wrong place (obvious from the error)
Anyone know why?
Got it fixed guys. It was the permissions to the installation folder. My user was set to "read/write only"...once i switched it to Full Control, everything worked fine