My Project is in a shared drive //company/me/project/
I have full read/write access to //company/me/
I have 0 access rights in //company/
Once in a while my Rstudio crashes with the following message
Unexpected exception: rstudio_boost:filesystem::status: Access is denied: "//company
After this i can no longer open my project via Rstudio.
The only workaround i have found is to delete .Rproj.user and create a new project in the same folder
Why is Rstudio trying to access //company/? Is there a configuration I can set to prevent this from happening?
Edit: I have noticed that this usually happens when theres a bug in my code or when I try to stop code that is running.
A possible reason can be that Rstudio (along with R), saves your session to a .Rdata (either by default or possibly because you clicked "Yes" when it asked to save the workspace to .Rdata). R does this to track reproducibility of a session i.e. to determine the last state when Rstudio was closed (or crashed in your case).
And now its trying to restore an exception , which cannot be reproduced as it requires opening up the file and running it (and opening it, is what you want in the first place).
Note that as per RStudio Documentation: .Rproj.user also stores project-specific temporary files (e.g. auto-saved source documents, window-state, etc.).
A recommended solution to this is to set option for never saving the session data i.e. every time Rstudio starts , it is starting with a clean slate for your project. If you are concerned about loosing the commands you ran in your last session , set the option of Always Save History (Even when not saving .RData). See the image below to set things as a default (sourced from Hadley's Comment):
The same settings are also present for a Project too:
Related
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've been working on a Cordova app, and I've suddenly had troubles with Chrome.
I've wanted to start debugging, so I added support for a browser platform, and I use Chrome.
After running the app on Chrome, which worked before, I encountered this problem:
Failed To Create Data Directory
Google Chrome cannot read and write its data directory:
C:/Chromedevsession"
screenshot here: http://prntscr.com/876kax
Things I tried:
Deleting Chrome -> Reinstalling Chrome - found this online
Deleting Windows registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome - there's no
Chrome folder or key inside the Google folder, only an Update folder
While uninstalled, using a different browser as my default browser - the command that runs the app (cordova run) didn't open another
browser (I tried Firefox).
It already worked before, and I don't know why it suddenly happened. I tried upgrading to Windows 10 a few times and it failed, so could there be a problem in the registry?
I solved this issue by editing the run file (platforms/browser/cordova/run) and removing the speech marks from around C:/Chromedevsession on line 33.
The line now reads:
spawn('C:/Program Files (x86)/Google/Chrome/Application/chrome.exe', ['--user-data-dir=C:/Chromedevsession', '--disable-web-security', project]);
This is because the script that launches chrome, uses a folder location that typically can't be created with your permissions. That folder is used for history, bookmarks, cookies, etc (ie user data). This is beneficial for testing out features in Chrome (plugins, etc) and not affecting your normal instance. I don't consider it much of a concern here, more of a nuisance message. If you don't like it you could always just manually create that folder on your system as well.
You can see this here what causes the issue
switch (process.platform) {
case 'darwin':
spawn('open', ['-n', '-a', 'Google\ Chrome', '--args', '--disable-web-security', '--user-data-dir=/tmp/temp_chrome_user_data_dir_for_cordova_browser', project]);
break;
case 'win32':
//TODO: Use regex to fix location of chrome.exe
//TODO: Get --user-data-dir to work for windows
spawn('C:/Program Files (x86)/Google/Chrome/Application/chrome.exe', ['--user-data-dir="C:/Chromedevsession"', '--disable-web-security', project]);
break;
}
Since it can't use that folder, I believe it just reverts to the defaults which on Windows 10 would be
C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data\Default
Remove Space in Path in Registry Policy
HKEY_CURRENT_USER\Software\Policies\Google\Chrome\UserDataDir
or
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\UserDataDir
Example:
${roaming_app_data}\Google\Chrome\User_Data
instead of
${roaming_app_data}\Google\Chrome\User Data
There is a simpler solution to this. Just specify the full path to the special directory you want to use for your debug chrome instance. In my case I set the user data directory to a folder next to the default user data directory, called "Debug". The following works for me specified as a script in my package.json:
"start-remote-debugging-browser": "C:\\PROGRA~2\\Google\\Chrome\\Application\\chrome.exe -incognito --app=http://localhost:4200/ --remote-debugging-port=9222 --user-data-dir=C:\\Users\\mmcin\\AppData\\Local\\Google\\Chrome\\User Data\\Debug"
Is there an easy way of generating the memory dump for the crashed application?
I have a situation in which the customer received the code which is generating the crash, as the code itself has no signal handlers for the backtrace generation on abort I was wondering if there is an easy way of telling windows to generate the memory dump of the crashing application.
Ideal solution wouldn't involve the installation of the debug tools (or the code modification) but if this is not possible, it would be really helpful to know.
One simple way to dump memory when application crashes is by using windows taskmanager.
When ever an exception or an application error occurs windows pops up an memory dialog and shows the address location which was causing a crash.Before you click ok on the message box open Task Manger and right click on the crashed application and select Create Dump file.Take a look at the screen shot below.
Select the file
2)Another way of generating user mode dumps is by adding the following registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting >\LocalDumps\application.exe
application.exe should be replaced by the application name which is under scanner.
under this key following values can be added
DumpFolder
The path where the dump files are to be stored. If you do not use the default path, then make sure that the folder contains ACLs that allow the crashing process to write data to the folder.
For service crashes, the dump is written to service specific profile folders depending on the service account used. For example, the profile folder for System services is %WINDIR%\System32\Config\SystemProfile. For Network and Local Services, the folder is %WINDIR%\ServiceProfiles.
DumpCount
The maximum number of dump files in the folder. When the maximum value is exceeded, the oldest dump file in the folder will be replaced with the new dump file.
DumpType
Specify one of the following dump types:
0: Custom dump
1: Mini dump
2: Full dump
CustomDumpFlags
The custom dump options to be used. This value is used only when DumpType is set to 0.
The options are a bitwise combination of the MINIDUMP_TYPE enumeration values.
I have found the answer myself, the msdn specifies the debug registery in the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error\LocalDumps
The following values need to be set:
DumpFolder
DumpCount
DumpType
CustomDumpFlags
The extensive documentation is available here.
If the registers do not exist it is possible to create them manually and windows will pick it up.
Also this is possible without directly modifying the registry with following steps:
Click Start, and then click Control Panel.
Double-click System, and then click Advanced system settings.
Click the Advanced tab, and then click Settings under Startup and Recovery.
In the Write debugging information list, click Small memory dump (64k).
First of all, I'm not using Core Data, I'm using SQLite only.
I save the data in the table and then query them by opening the app and looking at the data using SQLiteStudio. I even create a LOG to check that the data is saved, and yes, it is saved.
But when I STOP and run the simulator again to consult, there is no more data!
Is Xcode overwriting the database every time? Or is something else happening that is outside my limited knowledge?
Without knowing more about how your application is setup, how you've got your app configured to build, or how it operates on the SQLite DB file in question I'll only be able to offer some pointers in things you can go check out about your code and build configuration that may be the source of your phantom deletions. Of course, if you have other info to provide, I'd be happy to edit my answer!
Case 1: 'Create DB' always running?
One thing that may be tripping your app up is what happens leading up to the decision to create a new SQLite DB file or look/open an existing file. If the code creating an empty DB is always running, then each time your app starts, your old DB file is getting overwritten with a blank DB.
Case 2: Using a 'starter' or 'template' empty database?
Sometimes developers may provide a blank database that contains the initial database schema (the general tables and structure) as well as some default or sample data. If your app does this, perhaps the logic leading up to the decision to apply that default database is accidentally always being triggered? If so, use of NSUserDefaults to record a boolean indicating the DB was successfully created may be an avenue to use to skip past the 'Load my starter DB' code. Alternatively, you could check for the existence of your DB file, or see if the contents of a specific table are different from the template data, etc.
Case 3: Different Behavior between 'Build & Run' vs. 'Run Without Building'
There's a not-so-well-known option in the Product > Perform Action menu labelled 'Run without Building' that will essentially kickoff another Debug session using the version of the application you just finished running in the Simulator or on Device. When you use this option do you see any different behavior with your database or is it still blank?
Case 4: Different Behavior when run directly in Simulator outside of an Xcode debugging session?
Part of the 'Run' operation is a build phase which may trigger the 'Copy Resources' phase even if your app hasn't changed since the last execution (as you suggest is the case in your question). If you are providing a stock 'default' or 'template' DB file and your app is simply opening and editing that 'template' during the first execution of your app, then Xcode may be replacing it with a clean copy on the subsequent 'Run' operations where 'Copy Resources' is happening. A way to test this avenue:
Build and Run your app to the simulator using Xcode like normal.
Perform some operations that would result in the creation or editing of data in your app's database.
Click the stop button in Xcode to return to the Simulator home screen.
Double-click the home button on the simulator (or if there is no home button, press CMD+SHIFT+H twice to bring up the multitasking bar and force-quit out of your application.
Check and see if your DB file has data in it.
If no data, then there is an issue persisting your changes into the database and we need to get that problem solved first. Otherwise:
Relaunch your app directly from iOS Simulator and perform different operations that would result in more or different changes to the database.
Click on the home button to return to the iOS Home Screen.
Force-quit your appellation as was done in Step 4.
Check and see if your DB file data has changed (but still has data) or has blanked out.
Finally, make sure you are following Apple's guidance about where to store user-data, if you are inadvertently storing something in an incorrect file path doesn't typically result in blanking of data, it may be prohibiting writing of data which could be interpreted as your data getting overwritten especially if you are interrogating it while it still is residing in an in-memory process. There's some really useful guidance about file paths in the Table 1-1: (http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html)
Locating your Simulator App on your Mac's Hard Drive
To be thorough (and you may already know about this!), iOS Simulator applications are stored on your Mac's hard drive just like other files on your machine. Their organization mimics that of a physical iOS device. To get to your App and its data:
Open a new Finder window.
Press CMD+SHIFT+G or choose 'Go to Folder' from the 'Go' menu.
Paste the following into the 'Go to Folder' box then click 'Go': ~/Library/Application Support/iPhone Simulator/
Select the folder that matches the iOS version of the simulator you built to.
Click on Appications.
You'll then be presented with zero or more folders, each folder that appears will have a string of digits separated by hyphens. Navigate through this list until you find the one containing your app. You can then browse, and copy data out of this folder to somewhere to be examined by other tools on your Mac.
I have a very simple VS2005 deployment project that aims to install for all users on a PC.
All the application files are written to %Program Files%\MyProg. A shortcut is created in the start menu and the startup folder. No registry settings or anything else are created. I have set
'InstallAllUsers' to true.
The created MSI runs fine and installs the software. It works without any problems when running under the user account from which it was installed.
When logging in as another user, the start menu and startup icons are present. It attempts to launch the application however an installation window pops up and states that 'the feature you are trying to use is on a network resource that is unavailable.' The installer will only proceed if pointed to the original MSI file.
Why does this happen? I want my application to be installed completely for all users when it is installed by a single user.
edit: Solution
I was getting similar event log messages as shown on this page. In my case it turned out to be as simple as ensuring that the User's Program Menu had its 'AlwaysCreate' attribute turned to false. If it was true, windows would try and recreate the folder when a new user logged in. This somehow required the invocation of the installer and thus resulted in the 'please insert the installation media' prompts.
It is actually kind of hard to say without some more information. I would recommend checking on the rights in the installed folder (seeing if only the one who installed it has rights) and also checking the file list for the directory (to make sure VS didn't automatically place some files in the user profile). Let me know what comes out from those two steps and we can try to keep digging if that didn't shed any light on it.
Keep in mind chances are this is most def not specific to Visual Studio, look at this MS support article here where the same message is coming back for office.
I know this is an old post but I thought I'd add another cause and solution in case the above didn't work for you.
There is a bug in VS Setup and Deployment Projects which results in registry values being entered into HKCU instead of HKLM irrespective of the InstallAllUsers property being set to true.
You must use Orca msi editor to change the registry root for "DesktopFolder" and "ProgramMenuFolder" from either 1 or 2 to -1. The issue cannot be resolved via VS.
http://www.qa.downappz.com/questions/vs-2010-deploys-per-user-features-during-install-which-require-access-to-install-media.html