OS.File/OS.Path → IOUtils/PathUtils

[Dan Stillman]

I mentioned this in another thread, but just to highlight it separately,
OS.File and OS.Path are going away in Firefox 115, so file operations
that can't use Zotero.File methods should use IOUtils and PathUtils
instead. They're mostly drop-in replacements, with a few minor tweaks
and enhancements.

https://firefox-source-docs.mozilla.org/dom/ioutils_migration.html
https://searchfox.org/mozilla-esr102/source/dom/chrome-webidl/PathUtils.webidl

We've added these to the plugin sandbox in beta 28, which will be out
shortly.

Where possible, you should continue to use Zotero.File methods (e.g.,
putContentsAsync()).

Let us know if you have any questions.

- Dan

[Emiliano Heyns]

Are IOUtils and PathUtils available in Zotero 6? And in chromeworkers (6 and 7)? I have a hybrid plugin with 6/7 compatibility. When you say this is something that will affect Zotero when going to 115, that means something after the 7 release, that I can work on while Zotero 7 is in production and 6 is deprecated?

Is this right wrt replacements?

OS.Path.join (replacement: PathUtils.join? joinRelative?)

OS.Path.basename (replacement: PathUtils.filename)

OS.Path.dirname (replacement: PathUtils.parent)

OS.Path.split (replacement: PathUtils.split)

OS.Path.normalize (replacement: PathUtils.normalize / Zotero.File.normalizeToUnix, although the latter also replaces backslashes, so not a 100% replacement)

main thread (async):

OS.File.makeDir (replacement: IOUtils.makeDirectory / Zotero.File.createDirectoryIfMissingAsync)

OS.File.exists (replacement: IOUtils.exists, no method on Zotero.File)

OS.File.read (replacement: IOUtils.read/readUTF8, Zotero.File.geContentsAsync/getBinaryContentsAsync)

OS.File.stat (replacement: IOUtils.stat, no method on Zotero.File)

OS.File.DirectoryIterator (replacement: IOUtils.getChildren, Zotero.File.iterateDirectory)

OS.File.remove (replacement: IOUtils.remove, Zotero.File.removeIfExists)

OS.File.writeAtomic (replacement: IOUtils.write/writeUTF8 with tmpPath set, Zotero.File.putContentsAsync)

OS.File.move (replacement: IOUtils.move, no method on Zotero.File)

chrome worker (sync): no replacements as far as I can tell from those two links

OS.File.exists

OS.File.read

OS.File.stat

OS.File.makeDir

OS.File.copy

OS.File.removeDir

OS.File.DirectoryIterator

OS.File.writeAtomic

The chromeworker methods going async would have a pretty significant impact on BBT

[Dan Stillman]

On 8/5/23 5:08 AM, Emiliano Heyns wrote:
> Are IOUtils and PathUtils available in Zotero 6?

No.

> And in chromeworkers (6 and 7)?

Don't know.

> I have a hybrid plugin with 6/7 compatibility. When you say this is
> something that will affect Zotero when going to 115, that means
> something after the 7 release, that I can work on while Zotero 7 is in
> production and 6 is deprecated?

We suspect we're going to need to update to Firefox 115 before Zotero 7
ships to address bugs/limitations in 102, and we're currently working on
a 115-based build. The breaking changes we're aware of so far seem like
they'll mostly affect us, not plugin developers. We're flagging this one
because it's the main exception we're aware of, but for the vast
majority of plugins it should be trivial. (I understand that BBT is not
like most plugins.) For our own purposes, we're writing a temporary
OS.(File|Path|Constants.Path) compatibility shim for 115 while we update
old code, and others would be welcome to borrow that, so you can
certainly just continue importing osfile.jsm for now and deal with this
once there's a 115-based build.

Mostly off-topic, but honestly I just think you're creating a world of
pain for yourself by trying to use the same code between 6 and 7. Make
It Red showed a variety of options, but I think you'd be far better off
following the 1.1 model, freezing BBT as an overlay plugin, and
continuing development on a Z7-only bootstrap. We have every intention
of shipping Z7 this year.

[Emiliano Heyns]

I'd be glad to take a look at that shim when it is available.

I'm not really looking for a world of pain, but this puts me in sort of a bind, with 3 non-optimal choices:

1. I postpone any real work on Zotero-7 compatibility until release is imminent, so that I can keep doing fixes or enhancements on the Zotero 6 line of BBT. This is what I did for the 4 to 5 switch and that was not fun.
   
2. I keep trying for a 6/7 compatible plugin as I've been doing so far.
3. I freeze BBT except for critical fixes and switch development to 7.

I understand you are recommending approach 3, and I will take that under serious consideration; the hybrid plugin has been a ton of work (I've spent most of my summer holiday on getting 7-ready and I wouldn't half mind just doing nothing for a few days), and it's proven difficult keeping the 6 line production-ready while working on a 7-line), but a long freeze would likely be problematic for BBT.

[韩小土]

Which function should I use for OS.File.copy?

[Dan Stillman]

On 8/6/23 3:51 AM, 韩小土 wrote:
> Which function should I use for OS.File.copy?

I linked to the migration guide in my first post.

https://firefox-source-docs.mozilla.org/dom/ioutils_migration.html#copy-a-file

[韩小土]

It works. Thanks.

Is there the Zotero.File.** function for OS.File.copy?

[Dan Stillman]

On 8/6/23 5:00 AM, 韩小土 wrote:
> Is there the Zotero.File.** function for OS.File.copy?

No. There's copyDirectory(), but Zotero.File isn't meant to be a full
abstraction of OS.File/IOUtils — it just provides some common operations
we rely on in Zotero that are (or used to be) more complicated with the
file APIs alone.

It does predate OS.File/IOUtils, though, so there's some duplication of
things that are now easy in IOUtils. So `Zotero.File.putContentsAsync()`
maybe wasn't the best example, since `IOUtils.writeUTF8(path, str)` is
pretty easy, but Zotero.File obviously has the advantage that we'll
update it as necessary as file APIs change — e.g., we'll make
`copyDirectory()` just use `IOUtils.copy(srcPath, destPath, { recursive:
true });`. But ideally IOUtils will stick around for a while, so if you
want to use that directly for something, that's fine.