# clean up nsIFile interface

RESOLVED FIXED in M18

Core
XPCOM
P3
normal
RESOLVED FIXED
18 years ago
18 years ago

Trunk
M18
arch
Points:
---

## Details

(Reporter)

### Description

18 years ago
Name of delete should be changed.
What else? As I recall there were a number of issues here.
(Reporter)

### Updated

18 years ago
Keywords: arch, nsbeta3
(Assignee)

### Comment 1

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


### Updated

18 years ago
Whiteboard: nsbeta3+
(Reporter)

### Updated

18 years ago
Whiteboard: nsbeta3+ → [nsbeta3+]

### Comment 2

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

/be
Depends on: 37406

### Updated

18 years ago
No longer depends on: 37406

### Updated

18 years ago
Target Milestone: --- → M18
(Assignee)

### Comment 3

18 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

### Comment 4

18 years ago
- Per last comments and no reopen - Marking Verified/Duplicate.
Status: RESOLVED → VERIFIED
(Reporter)

### Comment 5

18 years ago
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.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---

### Comment 6

18 years ago
(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.

(Reporter)

### Comment 7

18 years ago
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

18 years ago
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
(Reporter)

### Comment 9

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

### Comment 10

18 years ago
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

18 years ago
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
(Assignee)

### Comment 12

18 years ago
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

18 years ago
minusing per PDT rules.

Whiteboard: [nsbeta3+] → [nsbeta3-]

### Updated

18 years ago
QA Contact: leger → kandrot
(Assignee)

### Comment 14

18 years ago
nsIFile interface is pretty much stable.  Marking bug as fixed.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.