Each time a file is edited (Pdf, Google doc, ect.) there is a new revision. By default, Google drive deletes file revisions older than 30 days or 100 versions... How can I switch this off?
My end goal is keep all revisions of all files stored in Google drive.
I found this resource, but I don't know how to implement it yet. Would you please walk me through?
How to use the "KeepRevisionForever" property to keep all file versions
Thank you so much!
You want to set keepRevisionForever to true for the existing file.
For this, you can achieve this using the method of "Files: update" in Drive API.
Also, you can test the method at "Try this API".
Access to "Try this API" and set keepRevisionForever to true, then, when you set the file ID and click "EXECUTE" button, keepRevisionForever of file is set to true.
But in the current stage, unfortunately, it seems that there are no methods for checking whether keepRevisionForever of the file has already been true.
Related
How do you go about creating files at arbitrary locations given you have the absolute path? I want to create a file in some arbitrary location /Users/me/random/project3/<moreStuffInThePath. How would I go about doing this?
To create a directory I would do:
try FileManager.default.createDirectory(atPath: "/Users/me/random/project3/<directoryName>"
This worked fine for directories.
However the counterpart for creating files does not work:
FileManager.default.createFile(atPath: "Users/me/random/project3/something.txt", contents: someString.data(using: .utf8)) // always returns false
I have checked out other stack overflow threads on creating files. Everything I found was about creating files in the .documentDirectory or it was outdated.
Eg: How to create text file for writing
Create empty file swift
Read and write a String from text file
TLDR: How do I create text files/files with random extensions at arbitrary locations on the pc given I have the absolute path?
I would also be grateful if someone could explain why all tutorials available on this matter are about the document directory. Why is it so significant?
Thank you!
This is most likely because your app is sandboxed.
Go to your project settings, select the macOS target and go to "Signing and Capabilities". You should see something like this:
If your app needs to create files in arbitrary locations, you must remove the app sandbox by clicking on the "x" on the top right. Note that this will cause your app to be rejected from the Mac App Store.
If you want to upload your app to the Mac App Store, then you must keep the sandbox, and write to "user selected locations" only. Select "Read/Write" rather than "Read Only" next to "User Selected File". (Although it says "File", this includes directories too) This allows you to write to locations chosen by a user using something like an NSSavePanel.
I use rest api "https://api.onedrive.com/v1.0/drive/root/view.delta?token=***" "reference page" to get oneDrive files changes, it work for add file or folder or delete, but i need to get old path and new path for move, and get old name and new name for renamed file or folder.
Is there any way to get the rename and move changes?
The API doesn't return / track the old-state of items.
To accomplish this, you need to maintain that state in a cache by tracking items with their unique identifier. You can then process the changes coming from the delta API, and when the change record is returned to you, you can evaluate your current state vs. the new state provided by the delta API, and use that to have the old-name and new-name, or old-path and new-path.
I am working on a application in which i have to update all app related settings remotely.
App setings include
Text Font
List item
Text Color
background Color
Images
Url etc..
My idea is something like this, the first time when the user install the app it start downloading all images and settings like text color, font etc.
And when ever any changes happen the app itself downlaod those changes and store it locally.
Currently i am using a constant file where i have written all required settings.
Tell me some best way to achieve this and also tell me where to save the settings.
If is there any sample app available please provide me the link.
Thanks.
You could try something like GroundControl. It updates values in NSUserDefaults from a file found on a web server.
If you have a constant file from which you read all your settings, you can place an identically formatted file on a server, (maybe have a "last updated" date saved inside these files). Upon every session init, try to download the remote settings file - if it is "later" than the one you have, or any settings is different than the one you have saved, save the newly downloaded file instead of the old one, and act upon the changes.
The settings' flags and vars may change instantly across the app, while downloading images for skin and UI occurs immidiately after this, and take effect after they have completed downloading (which may look awkward to the user) or, more plausibly, upon init of the next session.
IMHO, using NSUSerDefaults settings and downloading a remote plist with the same keys and structure is most convenient file format for settings stuff.
Also, you may place the remote file in a web service, and have the client send that web service the request for the file accompanied with a "my last updated settings are of the date X" - the date of the latest settings you have locally. Then, the server may return a file, or an "you already have the latest file" response.
I would like a better workflow for debugging uploaded SCOs. As things are, I must edit a file in the activity, repackage, upload, and test. Often, I just need to change a single line of code. It would be VERY nice to be able to edit that file, that line of code, on the server. So far, all I've found is that Moodle manages the files, so it seems impractical to locate and decipher the renamed files after upload.
Is there a way to configure Moodle so that it doesn't rename and relocated files in SCOs upon extraction? Actually, I'm open to any suggestions on the best, fastest workflow for debugging SCOs.
Problem background
Since Moodle 2.0, files are no longer stored on server in the conventional /this/is/the/path/to/my.file way. Instead, files are rehashed and stored in Repositories (i.e. spread all over the moodledata folder as a collection of seemingly random data). This increases security and cross-OS compatibility but complicates stuff for people who would like to simply upload a SCORM zip package via FTP. Here's more information on file handling in Moodle 2.0
Path to the soluton
Let's locate the file you want to update, then update it.
Run phpmyadmin, go to mdl_files table, find your file by name in the filename field (let's say it's portrait.jpg)
Look at the contenthash field, it'll look like abcde1234567890. This means your file is stored in moodledata/filedir/ab/cd/ folder under the name abcde1234567890.
Rename the updated portrait.jpg to abcde1234567890, upload and overwrite.
Go back to phpmyadmin and update the filesize field in record for portrait.jpg with the size of the updated file.
Obviously, this process can be automated. You'll have to write a script that allows you to upload a file, then it'll search for that file in mdl_files, save it to the correct folder and update all fields accordingly.
Alternative idea
Enable external package type (and also enable 'Update on every launch'). Go to Site administration / Plugins / Activities / SCORM and check the box down below. Now you'll be able to launch SCORM packages directly from another server, so Moodle won't mess with it. Of course, you can run in other (probably cross-domain related) problems.
Sergey's answer is very good, with one caveat:
In his example with the contenthash of abcde1234567890, the file is stored in the moodledata/filedir/ab/cd/ folder under the name abcde1234567890. Moodle uses the full contenthash to name the file.
Our applications set the "do not back-up" flag as per Apple's requirements. Or at least we thought so. A recent submission has been rejected because the reviewer found a file without the flag set. We tested, re-tested and tested again and see that all of our files are created with the "do not back-up" flag. Hmmm!
This is not our first application using the same code base. We've had many others pass through with no issues even some quite recently.
So could it be a sequencing problem? We are copying a database file out of the download bundle that is used as the application's starting content; this content is then updated as the user gets more data. The initial database file can be large - as big as 2MB - depending on the application. We open a new file in the Documents folder, copy the database contents to the new file, close it, and then set the "do not back-up" flag.
Instead should we create an empty file and then immediately set the "do not back-up" flag, prior to opening it to overwrite the empty file with the database contents from the bundle?
I've asked the Apple reviewers this question but have not received an answer yet. I could simply try the different sequence and see what happens in the re-review, but I'd prefer to know what I should be doing and do it, rather than guess what the problem is and shoot in the dark.
So does anyone know of a sure-fire "Apple approved" way to copy out a (database) file from the bundle into the Documents directory and set the "do not back-up" flag? Can anyone shed light on any similar rejections and what they did to please the reviewers?
Having earned the Tumbleweed badge (= its a boring question) here is some information to answer it....
The way to set the "do not back-up" flag has changed between 5.0.1 and 5.1. The release notes for iOS 5.1 SDK has the following entry under "Backup"
iOS 5.1 introduces a new API to mark files or directories that should not be backed up. For NSURL objects, add the NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from being backed up. For CFURLRef objects, use the corresponding kCFURLIsExcludedFromBackupKey attribute.
Apps running on iOS 5.1 and later must use the newer attributes and not add the com.apple.MobileBackup extended attribute directly, as previously documented. The com.apple.MobileBackup extended attribute is deprecated and support for it may be removed in a future release.
Note that iCloud was introduced in iOS 5.01, and this change was introduced in 5.1, which means that the app must adapt to the iOS specific version running on the device. One of our developers found the following Gist for code that handles pre- and post- iOS 5.1 devices.