I'm using Google Code unchanged (except for the folder name) yet I get the error "Cannot find folder".
I've checked the spelling of the folder name and tried several different folders in "My Drive" but get the error on all of them. The exact same code works for my friend but not for me.
Here is the line of code:
var folder = DocsList.getFolder('My Docs');
Try to use the folder ID instead of the name.
var folder = DocsList.getFolderById("234asdfih-324asdf")
You can find your folder ID in the adressbar of your browser when you open the folder.
If you use the ID you can change the name of the folder later and it does not matter at all.
If you use the folder name watch that its case sensitive.
I faced a very similar but somehow different issue. Depending upon the folder name I include in CHECKLIST_FOLDER (and they are all valid), the command :
myFile.addToFolder(DocsList.getFolder(CHECKLIST_FOLDER));
returns (or not) the error message "Cannot find folder". Folders details and permissions are identical in all cases, no clear reason for failure.
In this case as well, Thomas' work around is working great, thanks !
Related
I am spending hours (literally) trying to find a way to change the DriveApp.Permission of my script (for web App).
Actually, its value is VIEW, not allowing me to create folders, files or edit them (read only).
The script is configured to run as "me", accessible for anyone.
I have checked the owner of the folder ( FOLDER.getOwner().getEmail(); ) and owner of the user/session ( Session.getActiveUser().getEmail() ).
Not surprisingly, they've returned the same value. I have read THIS, but without success in retrieving any useful information.
I think, the problem is around the DriverApp.Permission value.
I was brief as a possible, I think. Could someone help me?
To put it clear: the script, the driver, etc., all of them belongs to me ( \o/ ).
Example:
DriveApp.getRootFolder().getFoldersByName( "ExistingFolder" ).next().createFile( "No_authorized_it_will_not_be_created_and_will_trigger_a_exepction" , "Some TEXT" );
Google GET response (translated/approximated)
Exception: You don't have permission to call DriveApp.Folder.createFile. You need to have permissions :https://www.googleapis.com/auth/drive (line 135, file "InternalDriver")
With support of #Copper and suggestion of #TheMaster, my solution:
Add this JSON object to the manifest
"oauthScopes": ["https://www.googleapis.com/auth/documents", "https://www.googleapis.com/auth/drive"]
Create a new version of the project, and try it again.
I have removed the actual permission related to project before deploy a new version.
I'm not sure whether "https://www.googleapis.com/auth/documents" path is necessary for simple creation or edition of folders/files. The other path string is certainly needed.
I added this HTML to a page that I render via a REST call:
StringBuilder builder = new StringBuilder();
. . .
builder.Append("<p></p>");
builder.Append("<a href=\"/App_Data/MinimalSpreadsheetLight.xlsx\" download>");
builder.Append("<p></p>");
. . .
return builder.ToString();
My ASP.NET Web API project has a folder named "App_Data" which does contain a file named "MinimalSpreadsheetLight.xlsx"
The download link is indeed rendered on the page, and clicking it does appear, at first, to download the file (it has the Excel icon, and it bears the file name), but beneath that it says "Failed - No file":
Is the problem with my HTML, or the path I'm using, or file permissions, or what?
I've only tested this with Chrome, so far, BTW. IOW, it's not an IE issue.
UPDATE
I tried it with a leading squiggly, too:
builder.Append("<a href=\"~/App_Data/MinimalSpreadsheetLight.xlsx\" download=\"Spreadsheet file\">");
...yet, alas, to no avail.
UPDATE 2
I changed the pertinent line of HTML to this:
builder.Append("<a href=\"App_Data/MinimalSpreadsheetLight.xlsx\" download=\"Minimal Spreadsheet file\">");
...and it displays in the source like so (with some context):
<p>(Invoice Count excludes credits and re-delivery invoices)</p><p></p><p></p><a href="App_Data/MinimalSpreadsheetLight.xlsx" download="Minimal Spreadsheet file">
...but the link does not appear at all.
UPDATE 3
I was misled by this reference, which showed no text being added; I changed the code to this:
builder.Append("Spreadsheet file");
...(adding "Spreadsheet file" and closing out the anchor tag), and now the link appears; however, I still get the "Failed - No file" msg, and 2-clicking the "downloaded file" does nothing.
UPDATE 4
I tried two other permutations of what's seen in Update 3, namely with the forward whack reintroduced prior to "App_Data":
builder.Append("Spreadsheet file");
...and with both the squiggly prepended and the forward whack:
builder.Append("Spreadsheet file");
...but the results are the same in any of these permutations ("Failed - no file").
UPDATE 5
I also tried it without the "App_Data" at all, on the off change that is not needed:
builder.Append("Spreadsheet file");
...but the same "Failed - No file" is the result of that attempt, too.
UPDATE 6
Okay, so I tried this, too (single quotes):
builder.Append("<a href='/App_Data/MinimalSpreadsheetLight.xlsx' download='Minimal Spreadsheet file'>Spreadsheet file</a>");
...but no change. The file is there:
...so why is it not seen or accessible?
UPDATE 7
This:
string fullPath = HttpContext.Server.MapPath("~/App_Data/MinimalSpreadsheetLight.xlsx");
... (which I got from here) fails to compile with, "An object reference is required for the non-static field, method, or property 'System.Web.HttpContext.Server.get'
2-clicking the err msg highlights just "Server"
UPDATE 8
This (which I got from the same place as what I tried in Update 7):
string justDataDir = AppDomain.CurrentDomain.GetData("DataDirectory").ToString();
string url2 = string.Format("Spreadsheet file</button>", justDataDir);
builder.Append(url2);
...does nothing; clicking the link doesn't even give me a fake/failed download now...
justDataDir is:
C:\Projects\ProActWebReports\ProActWebReports\App_Data
url2 is:
Spreadsheet file</button>
UPDATE 9
I noticed on further fine-tooth-combing that url2 had a forward whack in it; I changed it so that all the whacks were back, but it made no difference to Update 8's results: clicking the link does nothing whatsoever.
If somebody solves this, it will definitely get bountified after the fact.
UPDATE 10
Maybe what I really need to do is, instead of the simple html, add some jQuery that will download the file. But the question is, can jQuery access the App_Data folder any better than raw/simple html can?
The app_data folder is used by iis and asp.net as a private area in which to put database files which can only be accessed by code running on the server.
If you try to access the folder directly via your browser you will get a permissions error.
In order to make the files available for download, move them the a folder under 'Content' (if you have an mvc site) and ensure that your web.config allows the .xlsx exention to be downloaded.
It may depend on what version of iis you are using.
Downloading Docx from IE - Setting MIME Types in IIS
chrome.fileSystem.isRestorable is a new part of the chrome.fileSystem API and it saif if a file can be restored with its entry or not. I've made many tests but something is wrong, when I tried to do :
chrome.storage.local.get(
["recentFileId1"],
function(recent) {
chrome.fileSystem.isRestorable(
recent["recentFileId1"],
function (isRestorable){
console.log(isRestorable);
});
});
It returns me true, even if the file has been deleted of my computer. recentFileId1 seems like a real id (many numbers and the path at the end, for example FD158F2A41037D17440C025C1CA5FE08:question.txt) and the file's restoration works if the file is still on my computer. When I tried to restore the file with an id of a deleted file it just returns nothing, no error.
So I want to know : did I use this feature wrong or something? It can work if I try to restore and see what is restored (if it returns nothing the file has been deleted), but I don't want to use a hack if the API is available.
Thanks.
This function is currently only available in the dev channel of Chrome, and should be released to stable in version 31.
What you're describing sounds like a bug, please file it at http://crbug.com. We should always return true or false. What the correct behavior in this case should be is not clear.
The intent of this function is to let an app know if it should provide UI to give the user access to previously opened files. If a file is restorable, it simply means the app still has permission to access the file.
We are reserving the right to limit when files are restorable. E.g. we might have an arbitrary upper limit to how many files can be restored, or the access might timeout after a few months, or we may give the user the option of not letting apps restore any files. isRestorable lets you know if access to a previously opened file is still available.
isRestorable is not intended to give information about how accessible the file still is. Local changes can impact this - e.g. the file might be deleted or the OS access permissions changed. It might still be there but be invisible to chrome and the app due to no read access to the containing folder.
Think about a recent documents menu. This could show files which were opened and since deleted. When the app restores a deleted app it would not work and would show an error to the user. At that point the user might go to their recycle bin or git checkout and replace the file.
Or the recent documents menu could just not show files which have been deleted.
Either way your app should not rely on isRestorable as an indication of whether a file entry can be regained and successfully used, you should handle restoreFile not restoring a file and giving an error, and handle access to the file having permission problems.
I've a file in a folder and I don't know anything about this file (how it's generated and updated) because it comes from an application running on my system of which I don't have the source code.
The file format is clearly json and I successfully created an hard link to it (using the shell command ln file hardLinkToFile) and placed it on another directory.
At this point I check the "2" files and they are exactly the same as expected, but when I perform an action in the application that cause an update of the original file the hard link doesn't get updated.
Any idea on how I can solve this problem?
UPDATE: As pointed out by both Vlad Lazarenko and mvds the file probably get deleted and a new one is created, is there something I can do to obtain a solution equivalent to the hard-link one I thought initially about?
If a hard link is not getting updated, it means that application is removing the old file and creates a new one. Thus, you still have a hard copy of the previous file, but new file has a totally different inode, though path is still the same. You can verify it simply by changing the content of that file yourself - the link should get updated.
I am getting the same behavior in TextEdit, but not in TextMate. I would suspect this is due to the revision control built in to OS X Lions document architecture. TextEdit uses versioning, while TextMate does not. Most likely this function replaces the file instead of changing it, as described by #Vlad Lazarenko.
#Vlad and Francesco. It's really in this way. I verified that vi leaves the inode unchanged and the src and dest file are both changed, while e.g. the kate editor doesn't and I was getting mad to understand why the changes I made in the src file weren't also in the dest file.
You can easily check this with the command ls -li srcfile destfile before editing one of them with each editor I mentioned.
By the way it's not nice that the hard link are application dependent
I guess it is a bit too late...
Anyways, accidentally I found that, if you change the default app for the file, the hard link gets separated from original file. Even if you click on change all and do not relate to that specific file.
I have installed MediaWiki (mediawiki-1.17.0) on Ubuntu 11.04, and it appears to be working fine. However, the location of the wiki is www.mysite.com/mediawiki-1.17.0/ which is a bit cumbersome. Instead, I would like the location to be www.mysite.com/wiki/.
I have tried renaming the folder, but this causes some configuration issues that lead to the wiki not being found.
How do I change the location of the wiki?
You have to edit your LocalSettings.php. In this file, go to the line no. 28 and change this to the below line:
//$wgScriptPath = "/mediawiki-1.17.0";
$wgScriptPath = "/wiki";
and change your folder name.
Source