46774 - clean up nsIFile interface

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[Warren Harris]

Name of delete should be changed.
What else? As I recall there were a number of issues here.

Comment 1

[Doug Turner (:dougt)]

I just remember delete --> unlink for a js namespace collision. 

Comment 2

[Brendan Eich [:brendan]]

If this is a dup of 37406, someone just resolve it as such.

/be

Comment 3

[Doug Turner (:dougt)]

sounds like it.  warren, please reopen if you know of any API changes other than
this renaming.

*** This bug has been marked as a duplicate of 37406 ***

Comment 4

[Tracy Walker [:tracy]]

- Per last comments and no reopen - Marking Verified/Duplicate.

Comment 5

[Warren Harris]

As I recall, people still didn't like the fact that nsIFile both represents a 
path and a file descriptor. Also, they weren't happy with the way paths are 
built up, ie. that it was indeterminant whether the thing named a file or 
directory until opened.

Comment 6

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

(How can you tell if you're dealing with a file or a directory without opening
it?  There exist filesystems, at least on Linux, that permit open() on a
directory-like thing, and which gives you the default file from the directory. 
Imagine /cvs/foo.c/1.1.4.2 vs. /cvs/foo.c .  Is just reporting the stat mode
what we want?)

Also, the interface for getting stat(2)-like data is broken, because it doesn't
let you detect changes with which you might race badly.  The nsIFileInfo
interface-struct thing was proposed as an alternative to the myriad IsFoo/GetFoo
methods on nsIFile.

Comment 7

[Warren Harris]

What I mean is that if you start with an nsIFile that refers to c:\foo\bar.txt 
and you append "baz" you end up with c:\foo\baz, but if you start with 
c:\foo\bar you end up with c:\foo\bar\baz -- not very intuitive.

Comment 8

[Brendan Eich [:brendan]]

Warren: you mean the .txt suffix changes the semantics of
append-pathname-component (or whatever it would be called in Lisp)?  Sick-o,
that's a bug. Anyone care to defend it?

Pathname component appending should be blind to the current pathname, it should
tack on the pathname component separator, and the new component (which must not
contain a separator, of course).  There could be a replace-terminal-component
method too, but no one would ever confuse that with append-....

/be

Comment 9

[Warren Harris]

Actually I thought it looked at the slashes, but now I'm not so sure about it. 
I'll take a look...

Comment 10

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

Brendan: why must the prefix not contain a trailing separator?

/src/mozilla/js/src//jsapi.h is a perfectly legal filename under POSIX, and many
pre-POSIX Unixes.

Comment 11

[Brendan Eich [:brendan]]

Shaver: sure, and trailing //s are meaningless even on pathnames naming 
non-directories in traditional Unix (although you told me Linux has added some 
bit of meaning to a trailing slash -- can you remind me what it is?).

But extra slashes are useless, and if nsIFile is promising an append-component 
method, it certainly can promise to avoid extra slashes.  Don't we canonize all 
paths coming in from the user (I mean normalize)?  Why should nsIFile allow or 
preserve extra slashes?

/be

Comment 12

[Doug Turner (:dougt)]

Two points.  First Filepaths:

All trailing seperators should be removed by nsIFile.  If you pass:

/home/dougt/foo/

and ask for the filepath back, it should return

/home/dougt/foo

This was decided long ago in one of the Brendan Arch meetings.


Second, I like the idea of a 'nsIFileLite' that would just encompass the file
location, but what gain is there?  Would this be a big bloat win?

Comment 13

[Judson Valeski]

minusing per PDT rules.

Comment 14

[Doug Turner (:dougt)]

nsIFile interface is pretty much stable.  Marking bug as fixed.