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.
Related
While trying to import some Android projects into Eclipse, I have noticed that every file in the project is 0 bytes after they are imported. These projects are stored on Drive, so there is some chance of reverting them back to the previous version.
Reverting files to previous versions is easy to do when you've got a few files - you simply do it through a browser. However, I have hundreds of files and I need to fetch one revision back for each. I have been able to download a number of files by hand thus far, but there has to be a better way.
I have asked Google support and actually got a response back, but it's clear that there is no built-in functionality to do this. So I have started looking at the Drive API but I can see that there might be a bit of a learning curve.
Wondering if anyone has run into this before? Ideally I would like to identify one folder and for each file underneath, fetch the last version of the file. If anyone has a good approach for this, I would love to hear it.
thanks!
The pseudeo code to do what you want is
# get the id of the folder https://developers.google.com/drive/v2/reference/files/list
fid=file.list(q=title = 'foo')[0]
# get the children of that folder https://developers.google.com/drive/v2/reference/children/list
children = file.children(fid).maxresults=999
# for each child,
for id in children.id
# get the revisions https://developers.google.com/drive/v2/reference/revisions/get
revisions = file.revisions(id)
# iterate, or take item[1] whatever works best for you, and use its downloadUrl to fetch the file
With each call that you make, you'll need to provide an access token. For something like this, you can generate an access token using the oauth playground https://developers.google.com/oauthplayground/
You'll also need to register a project at the cloud/api console https://code.google.com/apis/console/
So ye, it's a disproportionate amount of learning to do something fairly simple. It's a few minutes work for somebody familiar with drive, and I would guess 3 days for somebody who isn't. You might want to throw it up on freelancer.com.
I'm considering using Google Drive push notification in order to replace our currently pulling process.
I started playing with it, but I have 2 major problems:
Watching changes:
When watching for drive changes, I get notification with the new change id. But when I try to query it using: driveService.changes().get(changeId), I intermittently get 404. Am I doing something wrong here?
Watching files:
When watching for file changes, in case of a folder, I want to know about new files added to that folder, so I expected that when adding/removing files from this folder, the "x-goog-resource-state" will hold "add/remove" value while "x-goog-changed" will contain "children".
In reality, the "x-goog-changed" does contain "children", but the "x-goog-resource-state" is always "update", and there is no extra information about the added/deleted file.
Regarding deleted files, I know can get it by watching the file once I have it, but is there a way I can get updated about new files in a certain folder?
I was working on a similar project a few months ago. There are two things you can do to monitor changes on Google Drive :
Set Notification Push using : changes().watch()
Set Notification Push using : files().watch()
The 1st case sends you a request for everything that happens on the Drive you are monitoring, with very little information on what exactly has changed.
The 2nd case is less 'spamming', and you get to decide which folder to monitor.
However the tags on the change type are not accurate. when I was using files().watch() I tested all the use-cases, and I compared the headers of each case.
My conclusions are:
for a new file (or folder) creation inside yourfolder (yourfolder/newfile) the headers contain:
'X-Goog-Changed': 'properties'
'X-Goog-Resource-State': 'update'
which is the same when you move a file to yourfolder, or when you start following an existing file in your folder.
you get 'X-Goog-Resource-State': 'add' when you share with a user
as you can see, the header tags are not accurate/unique.
Also, note that the push-notification channel will not send you requests for files inside a folder inside yourfolder (yourfolder/folder/files). And the channel will expire at some point.
If you still have any questions, or want to know how to implement the code, let me know : )
I have been asked to update a system where header information gets injected into a tif via a 3rd party console application. I don't need to worry about that bit.
The part I have been asked to look at it the merge process that generates the header information.
The current file generated by the process is assumed as correct, before I make any changes, so I want to add this as an approved result, from that I can then check that the changes I make will alter the file as expected.
I thought this would be a good opportunity to look at using ApprovalTests
The problem I have is that for what ever reason the links to the videos are considered corruptible (Possibly show me kittens jumping into boxes or something, which will stop me working, which ironically means I slow down my work done because I cannot see any help videos).
What I have been looking at is the Approvals.Verify and Approvals.VerifyFile extensions.
But what appears to be happening is confusing me.
using VerifyFile creates a received file, but the contents of the file are just a line the name of the file I have asked it to verify.
using Verify(new FileInfo("FileNameHere")) does not appear to generate the received file that I need to flag as approved, but the test does return saying that it cannot find the approved tif file.
I am probably using VerifyFile completely wrong and might be looking at using Verify wrong as well.
useful info?
Might be useful to know, that as this is a legacy application, running as a windows service, I have wrapped the service in a harness that allows me to call the routines, so the files are physically being written elsewhere on the machine outside of my control (well there is a config, but the return of the service I call generates a file in a fixed location if it is successful). I have tried copying that into the Unit Test project, but that doesn't appear to help.
Verify(File) and VerifyFile(string) are both meant to verify an existing file. As such they merely setting the received file to the file you pass in. You will still need to move/approval/create the approved file.
Here is the pseudo code and process.
[UseReporter(typeof(DiffReporter), typeof(ClipboardReporter)]
public void TestTiff()
{
string tif = YourProcessToCreateTifFile();
Approvals.VerifyFile(tif);
}
[Note: if you don't have an image diff installed, like TortoiseDiff, you might want to use the FileLauncherReporter]
Run this, once you get the result, move the file over by pasting your clipboard into a cmd window.
It will move the temporary tif to your test directory with the name ClassName.TestTiff.approved.tif
After that the test should pass until something changes.
Happy Testing!
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.
My application stores its data in an Access 2010 database (accdb) file. It's password protected, which means it's encrypted w/ AES-128.
I'd like to add some meta data to the file that's publically available. This way older verisons of my application can investigate the file to see if it's even worth trying to open. Otherwise, they'll just get the dreaded "Unrecognized Database Format" error, which is usually associated with file corruptions.
In Windows, you can right-click on a file, click "Properties" and see attributes under the Details tab. I'd love it if I add attributes like the version of my application that last touched the file, and maybe other details. I'd like to avoid having a different file extension for each version of my app!
Is it possible to add some public meta data to an encrypted Access 2010 database?
You can add custom database properties : http://support.microsoft.com/default.aspx?scid=kb;en-us;q178745
You can change the file extension of an encrypted Access database and change the properties for that extension. The extension .enc is fairly descriptive and does not seem to be widely used.
The file will open normally when clicked and ask for the password. The icon will be recognizably Access and the description, "Encrypted MS Access" in this case, will appear under Type in a directory listing.
With NTFS, you can add an alternate data stream (ADS):
notepad.exe z:\docs\testde.enc:Extra.txt
Reading the stream:
more < testde.enc:extra.txt
More information: http://www.think-techie.com/2010/04/alternate-data-streams.html
http://www.irongeek.com/i.php?page=security/altds
This is a tough nut to crack! An application must read information about the ACCDB, but that information can't be stored in the ACCDB because you want the read without opening the ACCDB. And you can't use the suggested file system methods because this must work under Wine on Mac (I assume from another of your questions).
The only solution I can see is to create a companion file (with same base name but different extension) to hold the metadata. So if your application wants to know about SomeDb.accdb, it would look for a file named SomeDb.metadata and read that instead.
I suggested a kludge for your earlier question ... unfortunately this is another. :-) However, it's a simple kludge and it should work ... even on Mac.