I search over the internet, VSCode documentation and here in stack overflow, but I can not find a place explaining if ExtensionContext.globalState is a permanent storage solution or not.
With permanent I mean:
it survives across VSCode updates
it survives across extension updates
ideally it survives to extension uninstalls - installations
Which of the above points does the mentioned ExtensionContext.globalState fulfill?
Regards
In my experience, globalState does survive VSCode and extension updates. Even though it may not be documented, it's definitely intended to work that way, as you can see when looking at issues like this one where storage was being migrated due to some internal changes (however it sounds like it was possible to lose storage by skipping a version / going from 1.29 to 1.31 directly and due to some issues in the migration code).
Regarding extension uninstalls - this one is easy enough to test yourself, so I tested this on an extension I maintain that uses global storage. The global storage value was still present when after an un- and re-installation.
Related
Is it possible to mount Google Cloud Storage as a volume in a GCE instance for an application to access?
It is stil work in progress you can try s3fuse
Do not expect productional reliability just yet,
at least this was my experience about a month ago...
In addition to s3fuse mentioned in another answer, there are also gcsfs (based on s3fuse) and stormfs.
Note that I haven't tried any of them, so I can't speak as to how robust any of these solutions are.
Google has the official gcsfuse FS now. However, it's in the Beta and never will make it to stable release, since there are problems with the performance and stability which cannot be or are very hard to solve.
The performance degrades rapidly if you need to handle many small files. Also, scanning directories with many files (like find does) make take hours or days.
We have tried it for the production, but it has I/O errors occasionally. So now, we use it for the maintenance only.
I have an iOS app which stores data in the local directory. I'd like to be able to sync this data between multiple devices running my app. Currently this is using core data, but I'd expect to have to change to some text-based file storage system to make syncing easier.
I was expecting the DropBox API would make this nice and easy, and that I could tell the API to simply sync the contents of my data folder on startup/save. However it seems the DropBox API is nothing more than a glorified way of uploading and downloading files.
Am I wrong on this assumption? Can the DropBox API actually make it easy to keep a folder full of text files in sync? If not, is there some other service or even advice you can give? Syncing is hard - I was hoping DropBox would make it easier.
Using /metadata, getting information about the contents of a folder couldn't be easier. All you need to do is check the modified date, and if it's different than yours locally, perform the appropriate action. It will also give you the metadata for any file contents, so you can pick out which files need to be uploaded / downloaded / added / removed as necessary.
Any more functionality than this would be very application-dependent; you can decide for yourself when and how you want to deal with differing files.
Dropbox API Documentation
Won't repeat since Andy has answered your question, thought you may also find this tutorial helpful:
http://www.nanaimostudio.com/blog/2011/1/20/how-to-synchronize-your-app-data-using-dropbox-api.html
Check out the new DropBox Sync API.
As ohho mentioned, there's the DropBox Sync API available now which I think will do what you mentioned (I haven't tried it personally, as I integrated support for Dropbox in my app using the earlier SDK, before this came along). This will probably suffice if you're just working with dropbox.
In my case I've been starting to add support for additional online storage ("Cloud") services to my app, and am finding that it's somewhat challenging to deal with the differences between them in how they handle various concepts like authentication, version, naming etc. For example Dropbox's API references files according to their path, whereas Box's API references files according to their file id (which has an associated path, but I believe remains the same if the file is moved). Then there's also all the issues of conflict resolution (aka merging) which come about when multiple clients try and sync conflicting changes to the server.
I've actually been recently considering starting an open source project to develop a library which can connect to all the major services, and provide an abstraction layer that papers over their differences, and also handles the syncing process for you. I've actually got some code already (which I haven't publicly released to date) but could use that to get the project started.
Would this be of use to you? Would you (or any others) be willing to participate in such an effort?
(note to mods: I realise this may be deviating somewhat off-topic - sorry about that. If you can recommend a more suitable forum to discuss this I'd be happy to take the conversation there).
There is a RSS feed that can be limited to one of the shared folders but it kind of filters events to keep volumes low.
Hi
Since I'm always transferring files, primarily plain text for coding, between home and office, I was wonder if other coders would share their preferred method for doing this. Is version control, checking in and out, really the best way to sync remote data, or is there some other solution (ie 3rd party cloud based tools like drop box or...)
Would luv to get other people's opinions on this subject...
When sharing files and source across more than one machine there is always the possibility to loose something when not using some version control. I personally use git (a distributed version control system, actually, just the stupid content tracker) for everything, especially for stuff that is live on many machines.
The benefits of a light and distributed version control system are:
Obviously, the versioning ;)
Consistency gets checked.
You retain a history of all your changes.
You can flexibly branch and merge as you like, w/o running into trouble when having too many parallel trees you sync manually.
You get to know version control, especially, you get to love distributed version control.
You can literally share a repository with others, who in turn can branch/merge at their own leisure.
Even when using version control, you are still free to have snapshots lying around w/o any version control ;).
So, I am strongly against manually managing synchronization - even in a one-man-show of a project.
I create websites for people. I have given them the ability to edit certain areas of their published pages using CushyCMS. That works fine, and everyone is happy with it.
When I go to publish some of my more extensive changes, I first need to pull down the latest version that they have produced. Then I make my changes, and upload everything to production.
I would like to use some sort of version control in this process. This should be a classic update-edit-commit-publish workflow, but I'm not sure how to go about this. Basically I want to avoid pulling down everything locally and doing the commits. I only want to pull down what has changed.
I use filezilla, and it doesn't do a good job of identifying changed files. I can't rely on the filesize, because sometimes it stays the same. I can't rely on timestamps because the server time is different than my machine, and it never seems to work correctly.
How can I get around my problem? I use Notepad++, Subversion and FileZilla, but I'm willing to try other tools if they would make this process easier.
It comes down to CushyCMS's decision to edit files directly and not put the user-provided content in a database like WordPress, DotNetDuke, Drupal, etc. So the real answer is you can't get there from here and should look into migrating to a database backed CMS. Thats not what you want to hear though.
Version control will get you part of the way to concurrency but there is always the possibility of a user updating a page between your pull down and publishing the revised copy since your users wouldn't be checking into the version control system directly. That would require them to learn the version control system and negate the ease that CushyCMS (or any CMS really) provides. You'll want to try and find a system that allows your live site to be the Master to which you compare and check-out files from. I do not know of any mainstream systems that currently work that way.
I found that it was easiest to use a tool like Beyond Compare to handle the synchronization.
This is not strictly a technical question, however I feel this will be useful for many technical people as well.
I'm looking for a version management / backup solution which need not be only for source code. This could be for non-text files e.g. images.
The requirement is this -
Every time I save the file from within the application, it should create a version.
I should be able to add comments for say, major revisions.
At any time, there should be only one version current.
I should be able to view previous versions without doing a 'restore'
I should be able to move back and forth between versions.
A calendar feature showing the various versions of a file would be helpful, if I could get to it for a specific file from the Explorer context menu
I don't really need to compare different versions or anything like that.
Windows solutions only. I've looked at NTI Shadow and it comes a bit close to what I'm looking for.
Are there any paid / free / open source solutions for the above requirements?
Pretty much any version control system i know of supports binary uploads. Subversion (in short SVN) is free and pretty popular. If you also download TortoiseSVN you can handle everything from within Explorer.
The only requirement i cannot help you with is 1. automatic saving from within your application. But you can of course do this by copying over your old version of the file in the file system and committing your changes via TortoiseSVN.
PS for some reason i cannot connect to the SVN site right now. It might be down at the moment. It is still a great product, though :)
[not an actual answer, just a note about DVCS backup capabilities]
I would not advise for a DVCS (Distributed Version control System) like Git or alike for backup strategy.
As stated in DVCS Myths
So, why make backups of a source control server with so many backups?
It is improbable that many servers will suffer catastrophic hardware failures simultaneously, but it is not impossible.
A more likely scenario might be a particularly nasty computer virus that sinks its teeth into an entire network of vulnerable machines.
In any case, the probability of any or all of your backups becoming suddenly unavailable is really not the point.
The bottom line is that using independent clones as canonical backups (as opposed to temporary stopgaps) is a suboptimal strategy.
Security, for example, should be considered.
If you are using authorization rules to control access to specific portions of your repository, canonicalizing an arbitrary clone of the repository effectively renders those rules useless.
While this would rarely be a matter of practical concern in a controlled corporate environment, it is nonetheless possible.
(my imput:) Full data backup is not really possible with a DVCS, since it would implies all repositories push their changes to a "central" repository, which is not the main use case scenario in a DVCS (whereas with a classical VCS, anything committed is stored in one place)
The key win of DVCS for backups, then, is that you don't really need to invest in a "hot" backup.
When the server inevitably goes down, DVCS will buy you time. Lots of time. You'll essentially be running at full productivity (or very nearly so) while you rebuild your server from backup.
When changesets created during the server downtime are pushed back to the restored server, the freshly restored authorization rules will be reapplied and you'll be back on track.
So, for us:
hot "backup" is actually achieved with SRDF (Symmetrix Remote Data Facility), but that is commercial and is linked to our infrastructure which support LUNs duplication to achieve data replication.
incremental daily backup is achieved for a limited set of repositories (including some "central" Git repos), but in our case, with a custom tool.
I think you're looking for the benefits of a versioning file system that takes immutable snapshots of files upon each write. You could build this into a DVCS if something set up watches on files contained in the versioned directory (committing each time a file is changed) but that would get ugly, quick.
This topic was also explored in this question. I think your ideal solution would be a DVCS repository that resides on a versioning/cow file system of some type. This lets you manage revisions of each file independently of commits that you make in the DVCS.
Unless, of course, toxic revisions would not be an issue for you.
In order for this to be transparent to applications (i.e., would not need to have application implement a different API for saving/loading files to access these backup features), you'd want to do this in the Operating System, at its file system layer.
ZFS filesystem could be wrapped to provide the user interface capabilities you describe, but it is doubtful this filesystem would ever reach Windows (directly, at least).
A simpler way to think of this is to look at network storage systems which can provide you the features you need.
NetApp Snapshot offers capabilities that could be tapped to do this at the network storage level. It implements CIFS, so is definitely available on windows. Open your wallet.
If you think this is an extremely important feature, you may consider other OSes than Windows; filesystems and filesystem support in OSes other than Windows are more diverse.
I strongly suggest using subversion. I have used 4 different version control systems and have found subversion powerful and easy to use.
For windows this is the easiest server to install is Visual SVN
And Smart SVN is the best subversion client I've used.