Name of delete should be changed. What else? As I recall there were a number of issues here.
I just remember delete --> unlink for a js namespace collision.
If this is a dup of 37406, someone just resolve it as such. /be
Depends on: 37406
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
- Per last comments and no reopen - Marking Verified/Duplicate.
Status: RESOLVED → VERIFIED
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 → ---
(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/188.8.131.52 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.
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.
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
Actually I thought it looked at the slashes, but now I'm not so sure about it. I'll take a look...
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.
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
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?
minusing per PDT rules.
Whiteboard: [nsbeta3+] → [nsbeta3-]
nsIFile interface is pretty much stable. Marking bug as fixed.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.