Closed
Bug 17948
Opened 25 years ago
Closed 24 years ago
UNIX nsIFile not implemented
Categories
(SeaMonkey :: UI Design, defect, P3)
SeaMonkey
UI Design
Tracking
(Not tracked)
RESOLVED
FIXED
M18
People
(Reporter: dougt, Assigned: brendan)
References
Details
(Whiteboard: [dogfood-]implementation mostly complete, blizzard helping)
Reporter | ||
Updated•25 years ago
|
Blocks: 13320
Summary: [DOGFOOD] UNIX nsIFile not implemented → [DOGFOOD] UNIX nsIFile not implemented
Putting on PDT- radar. Porkjockey work. Not known why this is needed for
dogfood.
Target Milestone: M12
Rocking hard on this. I'll mail out diffs and the Unix files for review today.
*** Bug 14360 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Initial portions are in the tree.
shaver deftly dodges the oncoming M12 train. He will catch his breath and leap
aboard the M13 one as soon as it starts boarding.
Whiteboard: [PDT-] → [PDT-] implementation mostly complete, blizzard helping
We've just got Move/Copy and isContainedIn that matter right now.
Updated•25 years ago
|
Assignee: shaver → blizzard
Status: ASSIGNED → NEW
Comment 6•25 years ago
|
||
Taking ownership from the sickly shaver.
QA Contact: dp → shaver
You rule, blizzard.
I've got isContainedIn implemented, but I'm crashing in autoreg now
(dirIterator->GetNext in nsNativeComponentLoader::RegisterComponentsInDir), so I
can't test it. Foiled again!
I've got another build going now, in case that fixes it -- is anyone else seeing
this on the NSIFILE branch?
Updated•25 years ago
|
Target Milestone: M13 → M14
Comment 8•25 years ago
|
||
m14
Comment 9•25 years ago
|
||
Taking ownership and marking as beta1. This is something that I would consider
important for beta quality.
Status: NEW → ASSIGNED
Keywords: beta1
Comment 10•25 years ago
|
||
What's the status of this bug? As far as I know, we're running with nsIFile on
linux (all of necko uses it now).
Comment 11•25 years ago
|
||
There are still some things that aren't implemented yet. The following
functions aren't done:
nsLocalFile::Normalize()
nsLocalFile::CopyTo() ( just copying a directory. files work. )
nsLocalFile::CopyToFollowingLinks()
nsLocalFile::MoveTo()
nsLocalFile::GetDiskSpaceAvailable()
nsLocalFile::GetParent()
nsLocalFile::Spawn()
Updated•25 years ago
|
Summary: [DOGFOOD] UNIX nsIFile not implemented → UNIX nsIFile not implemented
Comment 13•25 years ago
|
||
nsIFile::Spawn() and nsIFile::Normalize have been checked in.
Comment 14•25 years ago
|
||
I have a version of GetParent as a patch over in bug 21100 - not sure if it's
the best way, but, it's good enough for the filecache to start working.
Component: XPCOM → XPApps
Comment 15•25 years ago
|
||
I'll take a look at it. A brief glance says it's ok but I'll have to test it.
Comment 17•25 years ago
|
||
Please ignore the spam. Changing address.
Assignee: blizzard → blizzard
Status: ASSIGNED → NEW
Comment 19•24 years ago
|
||
What is the status of this bug?
According to the comments it may be important for beta (nsbeta2 ?).
Comment 20•24 years ago
|
||
Putting on [dogfood-] radar.
Whiteboard: [PDT-] implementation mostly complete, blizzard helping → [dogfood-]implementation mostly complete, blizzard helping
Comment 22•24 years ago
|
||
Ok, doing a status update on this bug since the information given seems to be
WELL out of date.
Here is the current status:
::CopyTo is not implimented for directories.
::CopyToFollowingLinks is completely unimplimented.
::MoveTo is completely unimplimented.
::GetDiskSpaceAvailable is unimplimented for platforms without statfs.
Comment 23•24 years ago
|
||
The lack of MoveTo is blocking bug 37842 which we need to do XPI upgrades of
the product itself, skins, etc.
Keywords: nsbeta3
Comment 24•24 years ago
|
||
Yeah, I haven't had time to work on that at all. Sorry. :( Feel free to assign
it to dougt if you want.
Reporter | ||
Comment 25•24 years ago
|
||
MoveTo() is implemented on all platforms now. (Unix does a Copy/Delete - not
optimal)
Assignee | ||
Comment 26•24 years ago
|
||
Argh -- why does Unix not use rename(2) and only copy/unlink if rename fails
with EXDEV?
/be
Comment 27•24 years ago
|
||
dougt admits that's it's not optimal probably for this very reason
Assignee | ||
Comment 28•24 years ago
|
||
Who's gonna fix it? I can cough up a patch if no one else is gonna.
/be
Comment 29•24 years ago
|
||
Given that this bug has hung around unfixed so long, maybe you'd better just do
it.
Reporter | ||
Comment 30•24 years ago
|
||
remember that rename fails across volumes.
Comment 31•24 years ago
|
||
and that with recursive moves across volumes sometimes it will fail in the
middle if you happen to cross a filesystem border
Assignee | ||
Comment 32•24 years ago
|
||
Yeah yeah -- I mentioned EXDEV, didn't I? (Meesa implemented rename in Irix
some time in the late '80s.)
Blizzard, do you mind if I take this bug?
/be
Assignee: blizzard → brendan
Status: ASSIGNED → NEW
Comment 33•24 years ago
|
||
Sure, go right ahead.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M17 → M18
Assignee | ||
Comment 34•24 years ago
|
||
Maybe I should take bug 33098 and close this one?
/be
Reporter | ||
Comment 35•24 years ago
|
||
This has been fixed. All apis are implemented.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•