I am a high school CS teacher teaching C++ with Xcode. In the past, I have used Google Backup and Sync such that my kids shared a Google Drive folder with me, saved all their work locally in their Google Drive folder, and synced this folder with Google Drive's cloud. Worked like a charm. Now, our school has transitioned to Google FileStream, which works differently. Google Drive is now treated as a mounted volume and by default does not copy synced folders, but provides links to them on the cloud, so they appear to be local, but are in fact not. I am able to have my kids set their class folder in "offline mode" so that they can use it as before, maintaining local file copies as well as syncing with Google Drive's cloud. However, I just discovered that this results in a "permission denied" error when trying to execute their code. Projects build, but do not run.
I had them move their project folders to their desktop, and they build and run just fine. When saved on the FileStream mount, even attempting to run a successfully built project through terminal results in the same "permission denied" response. So I am 100% sure the issue here is trying to run executable code from the FileStream mounted folder.
Any thoughts here? Is there a Mac security setting somewhere that I cannot find that will allow this? Or is this a Google Drive thing? I can always have them work locally, then copy the project over, but that is a real pain for them and me with grading from home.
Related
I noticed today that on windows 10
some apps in the folder C:\ProgramFiles\WindowsApps... are protected in some way other than just the access permissions.
When installing Microsoft.MicrosoftEmulator_1.1.39.0_x64__8wekyb3d8bbwe.msix or Microsoft.253890156C685_1.0.0.0_x64__8wekyb3d8bbwe.Msix
as well as it seams other apps from the store
the Folders for those created in under C:\ProgramFiles\WindowsApps\ have some additional write protection.
While a cmd prompt started as TrustedInstaller can create and delete folders in the apps that come pre-installed in the folders fo these apps this fails with an access denied error.
Taking Ownership of those folders and files as well as adding full access permission does not solve the issue.
With a cmd prompt started as system it is at least possible to create or delete folders but for the existing folders created by the package installer its still not able to create a file within those.
This protection remains in place even when the system partition in question is mounted by an other windows 10 system.
The only way I found to gain full access to these files is to mount the partition in a windows 7 installation.
So it seams to me that MSFT has added som additional layer or patronizing the administrators which needs to be understood and broken.
Any ideas how to get around this issue?
Well however the restrictions are implemented with this driver: https://github.com/DavidXanatos/IgnoreACLs you can gain access to everything everywhere.
With minor limitations, renaming of files in protected locations does not work and creating of directories.
Other than that, modifying, creating and deleting files and folders works fine.
Power back to the owners of the devices.
is there a possibility to change the Dropbox sync folder (aka "Dropbox location") programmatically on Mac OSX? By programmatically I mean by executing some command line helper tool or by using the Dropbox API.
I've searched around for this quite a long while now, but couldn't find any satisfying answers.
Sym-linking or using an alternative cloud provider (with a possibly better CLI/API) as suggested here are not an option for me.
As I understand the Dropbox API, it is made for accessing the Dropbox Server storage from within one's own application rather than interacting with the "out-of-the-box" Desktop sync client, is this correct?
The solution I am looking for should also work very reliably, so "hacking" the encrypted SQLite dbx files (as suggested here) or an Apple UI script that changes the sync folder via the Dropbox UI Desktop client are also really not an option for me.
For Google Drive I know that doing this is a simple as stopping the sync client, moving the sync folder, changing the sync path in the sync_config.db accordingly and re-starting the Desktop sync app. -- Exactly such a procedure is what I would also be hoping to find for Dropbox :-)
THX for your replies & suggestions!
No, without using the potentially brittle methods you mentioned, I don't believe there's a way to do this programmatically.
Your understanding of the Dropbox API is correct though. Using the API allows you to communicate with the Dropbox servers directly to interact with the account, and not the local desktop client.
I find that when I install applications(.dmg files), they all are installed into the folder /Volumes.And some days ago, they were installed into the folder /Applications. I don't know my macbook had suffered what kind of attacks, improper use or something like these. Anyway, it changed. I don't know how to resolve it. Is there anyone who ever had that kind of problem like me?Anyone who know how to make my macbook back to install applications into /Applications folder by default?Or anyone who know how to specific the installing folder if the default installing folder is not I want?
You need to begin by understanding the difference between installing and application and running it from a disk image. The whole disk image situation is understandably confusing for users, but considering that this is a programming Q&A, here are the important points.
Macintosh applications are stored in special directories with the extension .app. Because of the extension, these files are known by the Finder and treated as special Bundles, which are shown to the user as a single icon which cannot easily be opened further (there are other types of bundles as well, but the .app bundles deal specifically with applications.
Because Macintosh applications are actually directories full of files and other directories, they cannot be downloaded as a single file through the Internet without some kind of packaging. Recently there has been a move to package these in standard zip files, because they are understood well by many platforms. For many years prior to this, though, Macintosh applications were distributed on mountable Disk Images (.dmg format files), which themselves were multi-file containers which could support a variety of files and directories.
The key problem in both cases is that applications, once downloaded, don't necessarily move themselves to the most obvious location (the Applications folder on the boot volume, where Apple-installed applications are stored). Zip files usually automatically decompress, but are left inside of your Downloads directory, and Disk Images are usually downloaded to the Downloads directory and then mounted on the desktop, showing up as a new volume under /Volumes and appearing in the Finder as a disk.
In most cases, applications can be run from any of these locations, leading to the particularly confusing situation of:
Download a disk image
Disk image file goes to the Downloads folder
OS X mounts the disk image
User runs the application just fine from the disk image
User reboots the Mac
Application appears to have disappeared
In this case, the application isn't gone, but the disk image was uncounted by the reboot, and so it isn't obvious to most users where the application has gone.
The most straightforward solution for users is to copy the applications to their Applications folder in order to make sure it is easy to find.
Obscure note: This works well for Disk Images (which can subsequently be deleted), but may cause some confusion for Applications decompressed from zip files if the Application was downloaded on a disk other than the boot volume. I this case, copying the Application may lead to having two copies of it, one in the downloaded location and one in the Applications folder. This can be very confusing if you delete the application as the Finder will still locate it in the Downloads folder. It can also be confusing when you download an update for the application manually, as it may result in multiple copies of the application in your Downloads folder. These will usually be named "My app", "My app 1", "My app 2", etc.
I have a pc and laptop. When I am in university I work on a project (Or soloution) on my laptop. When I get back home I really want to work on the project using my PC (I got dual screen and ofcourse my PC is thusands time faster!).
The projects are located in Documents\Visual Studio...... in my laptop and of course this folder is shared on the HomeGroup.
I can open the project in my PC but when I try to build the project I get some errors like this:
Error 1 Unexpected error creating debug information file '\\AMIGA\Users\Sean\Documents\Visual Studio 2010\Projects\MiniScope\MiniScope\obj\Debug\MiniScope.PDB' -- '\\AMIGA\Users\Sean\Documents\Visual Studio 2010\Projects\MiniScope\MiniScope\obj\Debug\MiniScope.pdb: Access is denied.
' MiniScope
And a warning like this:
Warning 2 Could not read state file "obj\Debug\ResolveAssemblyReference.cache". Access to the path '\\AMIGA\Users\Sean\Documents\Visual Studio 2010\Projects\MiniScope\MiniScope\obj\Debug\ResolveAssemblyReference.cache' is denied. MiniScope
Can someone tell me please how can I grant permission to this projects so they can compile and run?!
It's a security feature of Visual Studio. Network drives are considered untrusted (as others might change code or inject malicious stuff while you're working on it).
As a solution to this, I'd suggest not using a network share. Instead, use a tool to synchronize folders or a file hosting service such as Dropbox, SkyDrive or Box.net.
I never used the other two services, but Dropbox allows you to work with your Dropbox folder like any other folder (it's essentially just a standard folder observed by the service). Any modifications inside are mirrored on their server (secured/encrypted) and any PC or Android device you link with it. So you could link your PC and your Laptop, and the tool would do the syncing for you (using the internet or LAN, whichever is available (and faster)).
I'm working on a cocoa app that copies files to a user defined folder, and I'm currently testing it with a network drive. When I get the location of the network drive from the standard cocoa file browser, it looks like "/Volumes/Media". This works fine usually. There seems to be an issue though that I can't quite seem to work out where when I disconnect from my WIFI network, the Media drive remains mounted (I see it in /Volumes) but it is not accessible. Then when I reconnect the network, the drive is mounted to /Volumes/Media-1. I still see the original unusable /Volumes/Media drive until I restart my computer.
My question is a two parter. First, does anyone have any ideas why my drive may be staying "mounted" in my /Volumes folder even though I'm disconnected from the network. And secondly, I noticed that iTunes doesn't seem to be phased by this change of Volume name (from Media to Media-1). It is able to notice that the content it was originally accessing on /Volumes/Media, is now on /Volumes/Media-1 and continues functioning without a hitch. How might I go about detecting that name change and updating the path that I have stored in my app?
I'm trying this on OSX Lion by the way.
I asked the same question on Ask Different :
How to prevent the “-1” suffix in network drive paths?