503963 - Add a stat-like api for nsIFile

Status: REOPENED

(Core :: XPCOM, defect)

Description

[(dormant account)]

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.

Comment 1

[(dormant account)]

Attachment: proposed addition

Comment 2

[Benjamin Smedberg]

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...

Comment 3

[(dormant account)]

(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

[Benjamin Smedberg]

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.

Comment 5

[(dormant account)]

(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.

Comment 6

[Brendan Eich [:brendan]]

(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

Comment 7

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

(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

Comment 8

[David Teller [:Yoric] - still alive but not very active]

Well, we have a stat-like API for OS.File.
Do we still need this?

Comment 9

[(no longer active)]

(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?

Comment 10

[(dormant account)]

(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.

Comment 11

[(no longer active)]

(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.