Add a stat-like api for nsIFile

REOPENED
Unassigned

Status

()

Core
XPCOM
REOPENED
9 years ago
5 months ago

People

(Reporter: (dormant account), Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
currently isFile, isDirectory/etc cause individual stat() calls except on windows where the buggy(bug 456603) cache is used. 
I propose api that would mirror stat() behavior in returning a bunch of info at once. This will let us give up on cache abuse on windows, and make it easier to optimize stat() abuse.

Once the new api is added I plan to rewrite all existing instances of IsDirectory,IsFile,GetFileSize, etc to this new api.
(Reporter)

Comment 1

9 years ago
Created attachment 388369 [details] [diff] [review]
proposed addition
Assignee: nobody → tglek

Comment 2

9 years ago
Do you have evidence that multiple calls to stat() are actually hurting? When we removed the stat-cache on other platforms we found that the OS stat cache was more than sufficient. I'd like to avoid another API until moz2 when we can ditch nsIFile and just use paths...
(Reporter)

Comment 3

9 years ago
(In reply to comment #2)
> Do you have evidence that multiple calls to stat() are actually hurting? When
> we removed the stat-cache on other platforms we found that the OS stat cache
> was more than sufficient. I'd like to avoid another API until moz2 when we can
> ditch nsIFile and just use paths...

What do you mean by just use paths? I think waiting for moz2 isn't reasonable as when moz2 supposedly hits we may not have a good list of APIs to redo. It's nice to start on that incrementally.

On wince, it's 2-3ms per stat call on average. Attempted Windows stat-cache removal sounds like it caused a perf regression too. With a proper api we can get all of the benefits of a cache without the downsides. 

I'd also like to take this chance to cleanup the js side of things. If we could return a native js object with all of the metadata we'd save a lot on xpconnect(0.1ms).(my proposal doesn't include that yet).

It would also be nice to standardize on an api to read whole files into memory for both crappy platforms(wince) and crappy xpconnect overhead.

Comment 4

9 years ago
So if you're doing a new API, I'd like to avoid XPCOM. Create separate native and JS APIs of the following sort:

struct mozilla::stat {
  // whatever fields we really need... as few as possible!
};

void mozilla::file::stat(const nsACString& nativePath, mozilla::stat* result);
void mozilla::file::stat(const nsAString path, mozilla::stat* result);

And something equivalent as a JS module. The JS module might have to use xpconnect under the hood for a while, but eventually raw JSAPI would be better.
(Reporter)

Comment 5

9 years ago


(In reply to comment #4)

> void mozilla::file::stat(const nsACString& nativePath, mozilla::stat* result);
> void mozilla::file::stat(const nsAString path, mozilla::stat* result);

From irc, we'll also add:

 [noscript] nsIFile->Stat(mozilla::stat *result); for native code and
  js stat() call that takes an nsIFile.

I'll also like to mark existing stat()-calling nsIFile functions as deprecated and move the code over to new api ASAP after the api is landed.
(Reporter)

Updated

9 years ago
Blocks: 459117
(In reply to comment #3)
> (In reply to comment #2)
> I think waiting for moz2 isn't reasonable
> as when moz2 supposedly hits we may not have a good list of APIs to redo. It's
> nice to start on that incrementally.

Agreed. Mozilla 2 is rolling thunder at this point, at least for adding APIs. For breaking compat we have to pull the trigger, where the loud "bang!" from the gun firing is signified by the 2.x version jump. Or we could start breaking sooner.

Whatever we do, Mozilla 2 will not be freezing APIs as we did for Mozilla 1.0 many years ago.

Anyone disagree?

/be
(In reply to comment #6)
> Whatever we do, Mozilla 2 will not be freezing APIs as we did for Mozilla 1.0
> many years ago.

Can I expense a tattoo?

Mike
(Reporter)

Updated

8 years ago
Depends on: 563742
Component: XPCOM → XPConnect
Target Milestone: --- → mozilla2.0b10
Assignee: tglek → nobody
Component: XPConnect → XPCOM
Target Milestone: mozilla2.0b10 → ---
Well, we have a stat-like API for OS.File.
Do we still need this?

Comment 9

6 years ago
(In reply to comment #8)
> Well, we have a stat-like API for OS.File.
> Do we still need this?

That excludes C++ callers, doesn't it?
(Reporter)

Comment 10

6 years ago
(In reply to David Rajchenbach Teller [:Yoric] from comment #8)
> Well, we have a stat-like API for OS.File.
> Do we still need this?

I have no plans to continue with this. OS.File should suffice for majority of fs-operations in mozilla.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX

Comment 11

6 years ago
(In reply to Taras Glek (:taras) from comment #10)
> (In reply to David Rajchenbach Teller [:Yoric] from comment #8)
> > Well, we have a stat-like API for OS.File.
> > Do we still need this?
> 
> I have no plans to continue with this. OS.File should suffice for majority
> of fs-operations in mozilla.

That's fine, but not reason enough for a WONTFIX.  :-)  I think it might still be valuable to have this fixed if someone steps up.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
You need to log in before you can comment on or make changes to this bug.