OS.js BrowserFS Adapter

[saoirse-iontach]

OS.js BrowserFS Adapter

This is a BrowserFS VFS Adapter for OS.js.

OS.js is an open-source web desktop platform with a window manager, application APIs, GUI toolkit, filesystem abstractions and much more.

@BrowserFS is an in-browser file system that emulates the Node JS file system API and supports storing and retrieving files from various backends. BrowserFS also integrates nicely with other tools.

      ^{(- saoirse-iontach -)}

[coder0107git]

I'm a little confused. The @BrowserFS link takes you to your fork of ZenFS. What are the advantages of using your fork versus ZenFS or the old deprecated BrowserFS?

[saoirse-iontach]

Yes, it was very confusing for me too. James P claimed his @BrowserFS was the new browserfs ; At this time, it was mainly a fork, but still many unreliable changes, and that's why I have to fork and fix it. Some month later, he rebrand it as ZenFS and diverge a lot, an still not working.... (Still exist @BrowserFS organisation, but repositories have been moved to ZenFS)

Note: Don't confuse James P. BrowserFS/ZenFS with other existing homonyms.
BrowserFS is a project of John Vilk.
ZenFS is a Western Digital file system plugin for RocksDB.

• On npm:
  • BrowserFS is a jvilk package in npm
  • @browser-fs is an empty npm organization
  • @BrowserFS was a npm organization of James P.
  • @ZenFS is the new npm organization of James P.
• On github:
  • browserfs and zenfs are no interest organisations or users
  • browser-fs and zen-fs are James P. organisations

Yes, inconsistent names. That's what happens when you want to take advantage of the reputation of existing projects.

ZenFS should be avoid for now, and I will have to rollback to jVilk/browserfs.
In the meantime, my @BrowserFS fork is stable an working (storage and FSAccess).
(I have not tested nor fixed other backends)

Moreover @BrowserFS breaks compatibility with jVilk/browserfs, so that for now we can't reuse existing backends. Also it was a little insane to manage AMD and WebPack support because of split between Core and DOM ; I could have concatenated them, but initial intent was to work with requirejs and UNPKG to build a modular standalone OS-js.

As this 3 projects expose the same node:fs API, with some little implementation details, it should be easy to patch this adapter to work we any of them.

Main difference between old and new is :

• in jVilk/browserfs we interface with instantiable MountableFileSystem backend.
• in jamesP @BrowserFS we interface with singleton emulation modules.

Also I will have to investigate to found a reliable base version from github:jVilk/browserfs, because James P have done many change there. I think the reference should be the version published to npm, because people usually install from npm registry, but there are some fix in github.

[james-pre]

Hey @coder0107git, I just found this discussion and would like to address some inconsistent and incorrect information that was given to you.

... [redacted] claimed his @​BrowserFS was the new browserfs ; At this time, it was mainly a fork, but still many unreliable changes, ...

At the time, I was (and still am, to a degree), the current and official maintainer of BrowserFS. The decision to turn the majority of my work into a fork was based on the difficulty of getting changes out to the users. As jvilk was extremely busy, he could not administer to BrowserFS. Consequently, it was not possible for me to publish releases for the browserfs NPM package. I felt my changes could not be widely used, and opted to instead publish my work as a fork.

Note: Don't confuse [redacted] BrowserFS/ZenFS with other existing homonyms.

For clarification, @browser-fs and the NPM organization browserfs were my efforts to publish my changes. Unfortunately, this resulted in a lot of confusion from the community over whether it was official or not. Despite my continued assurances as to the legitimacy of the work, it appears it fell on deaf ears in many cases. This provided additional motivation for me to publish my work as a fork.

That's what happens when you want to take advantage of the reputation of existing projects.

This is libel. I never attempted to "take advantage" of the reputation of BrowserFS. In fact, I spent hundreds of hours putting work in to modernize the library. Only when I noticed confusion did I rebrand my work.

ZenFS should be avoid[ed] for now ...

There is no factual basis for this statement.

In the meantime, my @browserfs fork is stable an[d] working (storage and FSAccess).

My work is absolutely stable, even releasing a 1.0 release at the start of this month. Furthermore, my work includes significant bug fixes not present in the fork of my fork.

I hope I was able to clarify the situation. Please let me know if you'd like any more information.