I'm creating "JSON fragment extensions" for Windows Terminal in my code, to create some "auto-generated" Windows Terminal profiles.
In the official docs, JSON fragment extensions in Windows Terminal, there are 2 locations recommended for storing fragments (if your application is not a Microsoft Store app):
For applications installed from the web, there are 2 cases.
The first is that the installation is for all the users on the system. In this case, the JSON files should be added to the folder:
C:\ProgramData\Microsoft\Windows Terminal\Fragments\{app-name}\{file-name}.json
In the second case, the installation is only for the current user. In this case, the JSON files should be added to the folder:
C:\Users\<user>\AppData\Local\Microsoft\Windows Terminal\Fragments\{app-name}\{file-name}.json
This seems straightforward enough, but there's some other documentation that describes the actual settings.json file location:
The path for your Windows Terminal settings.json file may be found in one of the following directories:
Terminal (stable / general release): %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json
Terminal (preview release): %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminalPreview_8wekyb3d8bbwe\LocalState\settings.json
Terminal (unpackaged: Scoop, Chocolately, etc): %LOCALAPPDATA%\Microsoft\Windows Terminal\settings.json
So, to be clear, these paths are not important if I'm creating profile fragment files, right? I don't need to choose a different path (%LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe vs %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminalPreview_8wekyb3d8bbwe vs %LOCALAPPDATA%\Microsoft\Windows Terminal) for the Fragments files because Fragments will always be loaded from C:\Users\<user>\AppData\Local\Microsoft\Windows Terminal\Fragments etc?
Disclaimer: I work for Microsoft.
So, to be clear, these paths are not important if I'm creating profile fragment files, right?
Correct! The locations Terminal looks for fragment files are well-defined and durable across different versions.
Related
Starting from Windows 10 Fall Creators Update (version 16299.15) and OneDrive build 17.3.7064.1005 the On-Demand Files are available for users (https://support.office.com/en-us/article/learn-about-onedrive-files-on-demand-0e6860d3-d9f3-4971-b321-7092438fb38e)
Any OneDrive file now can have one of the following type: online-only, locally available, and always available.
Using WinAPI how can I know that the file (e.g. "C:\Users\Username\OneDrive\Getting started with OneDrive.pdf") is online-only file?
After years, I'm still using FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS attribute described here to determine if a file or a directory is completely present locally or not.
Microsoft docs says the following for FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS:
When this attribute is set, it means that the file or directory is not fully present locally. For a file that means that not all of its data is on local storage (e.g. it may be sparse with some data still in remote storage). For a directory it means that some of the directory contents are being virtualized from another location. Reading the file / enumerating the directory will be more expensive than normal, e.g. it will cause at least some of the file/directory content to be fetched from a remote store. Only kernel-mode callers can set this bit.
There are some advantages of FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS:
It can be used for both files and directories.
It can be set in kernel mode only, so there is no chance for anyone to set the attribute arbitrary.
And as it described in this answer, there are still some interesting undocumented attributes which can provide additional information about cloud files.
Note: I didn't accept Jonathan Potter's answer because I mentioned FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS attribute in comments and started using it a year earlier than he updated his answer.
To check for "online only" all you need is to call GetFileAttributes() and see if the FILE_ATTRIBUTE_OFFLINE attribute is set.
In fact this isn't new for OneDrive, that attribute has existed for a long time.
There are other OneDrive attributes available via the shell (although the property you need is PKEY_StorageProviderState rather than PKEY_FilePlaceholderStatus) but "online only" is easy to check for.
Edit: Another filesystem attribute, FILE_ATTRIBUTE_PINNED is new for Windows 10, and is used by OneDrive to indicate a file that's "always available".
Edit: As of 2019 it appears that OneDrive now uses FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS rather than FILE_ATTRIBUTE_OFFLINE, as suggested below.
Edit: PKEY_StorageProviderState was broken in Windows 10 1903, and still not fixed in 1909. It returns 4 ("uploading") for all files in any apps other than Explorer.
Take a look at the PKEY_FilePlaceholderStatus property for the file (at the shell level, not the file-system level). This blog post has a example program you can test. This question also hints to some undocumented properties you might want to take a look at.
Microsoft has a UWP example on MSDN.
Now with Sublime Text 3 and a year on from an older question, I'd like to bring this up again.
Is it possible to setup a Sublime Text project with network paths to folder resources that can be used on Mac(OSX) and Windows platforms.
We have projects which are already created in a windows dominant environment. We are looking to have these working in OSX as well. At the moment a path for a project resource would be mapped to a windows network drive for example Z. The folder setup in the project would look like this:
"path" : "/Z/Custom/Project1"
If I was to create a network mount on OSX and drag the same folder in, it might look like this for Mac:
"path" : "/Volumes/ENV/Custom/Project1"
Is there a way to get this working for both platforms specifically using absolute network paths as the project files do not exist in the same location, so relative would not be a solution here.
Network paths are simply handled differently on Windows vs. OS X. A Windows path might look like:
//server/path/to/file
or, if the server is mounted as a drive:
/R/path/to/file
whereas on OS X all network shares are mounted through /Volumes:
/Volumes/server/path/to/file
As I see it, you have two options. The first is the most obvious: separate .sublime-project files for Windows and OS X. However, depending on the complexity of your projects, this option may take some effort to keep both files in sync.
The second option is to just have both paths in the "folders" section:
"folders":
[
{
"path": "/Z/Custom/Project1"
},
{
"path": "/Volumes/ENV/Custom/Project1"
}
],
You'll have two Project1 folders show up in the side bar, but only one will expand - Sublime gracefully handles the fact that one path doesn't exist. The major issue with this solution is that you may have other project-specific settings that are platform-dependent. For example, I use the Anaconda plugin for Python that provides code completion, linting, and other features. A couple of its settings require the path to the Python interpreter you wish to use for each project, and these paths can be platform-specific, especially if you are using virtual environments.
I suppose there is a third option as well: write a custom Sublime plugin that runs on startup to determine the platform, then generate a .sublime-project file with the platform-specific settings. That would be a non-trivial amount of work and wouldn't allow for multiple users to share the same project file simultaneously (you'd have to store the generated file locally). However, depending on your priorities, it may actually be the best option.
Developing an extension for Mozilla Firefox I wonder if there is an "easier way" to what I do right now. Currently I do:
Create a folder - in which to develop - for example myextension
Inside this folder: Create and Edit the Files (like install.rdf, chrome.manifest, xul files. Basically all the other structure of a Firefox extension (no problem here))
Zip-compress the content of the myextension to a ZIP-file (i.e. named myextension.zip)
Rename myextension.zip to myextension.xpi
Install the xpi-file-firefox-extension then in firefox
Restart Firefox
Test the extention
After each edit to the codebase of the extension I need to undergo the process of 3. zip-compress, 4. Rename, 5. install XPI file to firefox, 6 restart browser.
Of course I could automate some of this but still I wonder if there is another way to develop the firefox extension directly in the running firefox profile folder .
The extensions I know are stored in the Firefox profile folder as:
firefox/profile/extensions/nameofextension.xpi
I cannot remember well, but I think that there was a way to have the extension being stored unzipped as a folder there too? This way I would still need to restart after edits but not do all the laboursome zipping-renaming-installing.
Any ideas?
It is possible to setup a directory to "in-place-edit" a firefox extension. By this the effort between editing and testing of the Firefox-extension can be reduced.
I have found the good explanation on the blog https://blog.mozilla.org/addons/2009/01/28/how-to-develop-a-firefox-extension/
Here I want to give the principal steps necessary to achieve the "in-place-edit"
Step 1: You have to find your profile directory of Firefox.
For example in Linux this would often be often something like this:
~/.mozilla/firefox/#%#%.default/
Step 2: Go to this profile directory
Step 3: If you already have any extensions installed (like for example adblock+ or noscript), then inside this profile directory you will find a folder named extensions. If you do not have yet any additional extension installed, it might be easy to simply install any, only to have the **extensions" folder be setup for you.
Step 4: In this extensions folder you can create a new directory (let us name it "myextensions_1"), which shall contain the stuff of your plugin. This stuff would be the ordinary things like the install.rdf, chrome.manifest files and the content,skin,locale subdirectories. In effect all the stuff you would normaly zip up to become the XPI file.
Step 5. Create a file that is equal to the content of the <em:id> tag that you used in your ìnstall.rdf file. So if you used <em:id>myextensionname#author.org</em:id> you need to create a file named myextensionname#author.org. Inside this file you will write the location of the "in-place-edit-extension-folder" we created before. In our example this we would have
the file myextensionname#author.org
which contains only the text ~/.mozilla/firefox/#%#%.default/extensions/myextensions_1
Of course the text depends on the location of the folder you use for your plugin.
If you did all things correctly - and maybe double-checked with the instructions of the link above - you can restart or "newly start" firefox. The browser will ask you if you want to allow the usage of the plugin myextensionname#author.org, which you can conceed.
Now you can edit in the folder ~/.mozilla/firefox/#%#%.default/extensions/myextensions_1 and need not to worry about zipping-up -> renaming -> installing.
You simple restart Firefox and the edits to your extensions code will become available.
This will allow you swifter and faster developing "in-place".
Note: this is a shameless self-plug - I am talking about an extension I created myself.
Developing an extension in place is possible but has so many issues (mostly caching of all kinds) that it really isn't a good option. Still, you can simplify your development cycle a lot. For that you need to install the Extension Auto-Installer add-on in your Firefox. Then you can put a batch file (assuming that you are developing on Windows) into your extension directory along the lines of:
zip -r test.xpi * -xi *.bat *.xpi
wget --post-file=test.xpi http://localhost:8888/
del test.xpi
The required command line tools are all preinstalled on Unix-based systems, for Windows you can easily download them: zip, wget.
Then you will only need to run that batch file to update your extension in Firefox. If your extension isn't restartless then Firefox will restart automatically. So this replaces your steps 3 to 6.
I'm doing this tutorial on how to setup your environment in creating a firefox extension and I don't understand this part:
Pointing to an extension
In your development profile folder, you will find a folder named extensions. In it, you will have code for all your installed extensions. Instead of placing your code there, you can create a pointer file. Do that by creating a file with a unique name for you (this will have to be the same as you chose for your em:id value in your install.rdf file – more on that below).
This part can be found in this link: How to develop a Firefox extension
I am doing it in Ubuntu. Is this the same as creating a symbolic link? I am confused on this part.
No, not all operating systems that Firefox runs on have symbolic links - so a different mechanism had to be invented. You need to create a text file with the name matching the extension ID and with the path to the extension directory as its contents. A symbolic link with the same name pointing to this directory should do just as well but might be less resistant if the extension manager decides that an update is available for your extension (update installation will remove the symbolic link and replace it by a regular extension install, not sure whether this happens with a text file as well).
Personally, I realized that properly installing extensions produces more consistent results - you don't get the ugly situation where some parts of your extension are updated while others are not. This is why I wrote Extension Auto-Installer (note: this is self-promotion), it simplifies the installation process a lot - especially when you are developing a restartless extension.
What I need is a directory which the user can handle as a single file in the Windows explorer. Does something like this exist? If not, what comes closest?
The closest thing is probably Alternate Data Streams, although those are more akin to MacOS Named Forks than Bundles.
There are also some special cases, for example if you save a website with Internet Explorer you get an HTML file and a folder which are linked together.
Depends on your particular needs. As mentioned above, named streams are possible (on NTFS), however you should notice that not all applications copy files with named streams correctly. In some scenarios regular ZIP archives can work (Explorer shows them as folders). If you are doing software development, there exist libraries that let you store many files in one container file (eg. SolFS).
I think you can create a folder with an extension, e.g. Myfolder.bundle, then you can associate that extension with a custom icon. So it looks like a bundle as far as the end user is concerned.