So I am making a VSCode extension. It should read and modify files of user's file system. Should I do it with node's fs or should I use some VSCode's interface/API for this?
If the latter is correct then what is the API namespace I need (workspace or something)?
If the former is okay, how can I really use fs? What if the user does not have node.js installed? Or is it always installed with VSCode?
It depends.
In general use vscode's TextDocument api for:
Reading text files from the workspace. This api ensures that you always read the current state of the file (even if it has not been saved to disk yet).
Modifying text file content in the workspace. You can also use save to write a modified file back to disk.
Reading resources from file system providers
Use fs for:
Reading and writing files that are outside of the workspace.
Reading and writing files that should not be tracked by VS Code. Opening a TextDocument can cause VS Code and its extension to try processing the file.
Reading and writing binary files.
This api proposal would also be of interest for you. It would enable more low level file reading/writing directly using VS Code.
(Also, you can always safely use node since VS Code includes a copy for extensions to use)
Related
what's currently possible in webassembly running in the browser regarding accessing the local file system? There's an older question that says it's not possible due to security restrictions. But some places (e.g. https://fjolt.com/article/javascript-new-file-system-api) say that there's a new file system API available in some browsers that would allow that.
a) what needs to be done to be able to use that api?
b) can I use it from rust with webassembly - and how?
Thank you for any useful pointer.
Tobias
The current web APIs (https://developer.mozilla.org/en-US/docs/Web/API) only lets you access files in the local files system by prompting the user to open or save files.
These APIs are not (yet) accesible from webassembly directly. So what you have to do is
Use javascript to prompt the user to open a file (or directory)
Grab the contents of the file and pass it to your webassembly code
Process the contents with webassembly (or in your case rust compiled to webassembly)
Pass the processed content back to javascript that can prompt the user to save the file.
or some variation of the theme above.
Read more about webassmbly usage here
https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_API
and Rust and webassembly e.g. here
https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_wasm
Does WebAssembly have the same issue as native JS(for very valid security reasons) that it cannot access the base/root path of any given uploaded file or selected folder? I want to write a Rust UI app with seed and using rfd (or its previous iterations nfd/nfd2) that users can indicate a file path so the application can install certain files in the correct place.
Otherwise can seed compile to a local .exe instead of a web based app, and therefore have proper access to the file system?
Thanks
I'm trying to use a software library to run some computations. These computations can be customized using a few configuration files in its share directory. Unfortunately this library only provides hard coded paths to specific files in its (read-only) share directory which store these default configurations. Thus right now only a super-user or administrator could modify them. The library doesn't search for any user-local versions of these configuration files. I'd like to develop a wrapper tool which additionally takes a path to an alternate version of one of these configuration files in the users home directory and have that file somehow appear to "mask" the original file on the file system for the duration of process execution without actually modifying the original file in any way (since it can't). Is there a Linux tool I could use to do this sort of thing?
I want to verify if certain exe files already exist in a merge module .ism (binary format). Is there a method of doing this without using InstallShield?
An *.ism file is really an MSI file with a changed extension. MSI files in turn are SQL databases stored as COM-structured storage files - a file system inside a single file with file streams for various content. This is the same format used in Office documents.
You can view MSI files with Orca from the Windows SDK: http://www.hass.de/content/how-install-microsoft-orca
Windows Installer XML (WiX) Deployment Tools Foundation (DTF) has an InstallPackage class available that exposes a FindFiles() method. This should be really easy to query the EXE. Just realize that being a merge module you won't know the full installation path as that's decided by the MSI generally.
Both of Chris's suggestions should work fine, as would using Orca. But it got me thinking there might be an even easier way using a tool called Merge Module Finder. It all depends on what you really want to do? Find files already in merge modules? Investigate what merge modules are in an Installshield file? It is not quite clear exactly what you want to do.
Though a bit clunky at times (I think the author hasn't updated it for the latest versions of Windows) it will help you look for a file in a bunch of merge modules interactively. You can also search for a registry value. Here is a screenshot:
I set up my working Core Data sqlite file for versioning. The versioning setup process created 3 files:
foo.sqlite
foo.sqlite-shm
foo.sqlite-wal
Since then, I can access the Core Data store programmatically (using MagicalRecord), but I can't read any data using either the Firefox add-in (SQLite Manager) or the app SQLiteManager. I'm concerned that when I send the updated app to the App Store, the additional files are not going to go and the app is going to crash.
What do I need to do to make sure new versioning-enabled sqlite files go with the app?
Those are not version-related files, they're SQLite log files. These files get created automatically when write-ahead logging is enabled. That's not the default in iOS 6, but it's possible if you use PRAGMA journal_mode=WAL;. It might or might not be the default in iOS 7 (I have no comment at this time).
I don't know why Firefox and SQLiteManager can't open the file. I speculate that they're both using an old version of SQLite (since WAL is only available as of SQLite 3.7.0). Regardless, they have nothing to do with whether the necessary files are available in your app. You can find out what's included in the app by just looking. The .app is just a directory, really, so take a look inside and see what's there.
If you are using lightweight migration (wich is enabled by passing the
right options when you open the store), Core Data takes care of
upgrading the schema in-place.
The additional WAL and SHM files are not a result of lightweight
migration, but are instead simply produced by SQLite in the “write
ahead logging” mode that Core Data puts it into. (An
oversimplification is that new data goes into the .wal file until
enough accumulates and then it is moved to the .sqlite file.)
Yes, you definitely want to test using Ad Hoc builds for lightweight
migration; testing from Xcode is insuffient.
Mike Fikes