Closed
Bug 1056442
Opened 10 years ago
Closed 3 years ago
OS.File.makeDir should not require `from` option for recursive creation
Categories
(Toolkit Graveyard :: OS.File, defect)
Toolkit Graveyard
OS.File
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: kmag, Unassigned)
References
Details
The `from` option seems to mainly be a (probably unnecessary) optimization, but it necessitates knowing a directory which is writable by the user, which exists, and which is an ancestor of the directory being created.
Using the `from` option where doing so is feasible and convenient is fine (though I still suspect an unnecessary optimization), but in cases where it isn't, it should suffice to add a `recursive` flag (or similar), which also implies `ignoreExisting`, as in `mkdir -p`
I have a quick-and-dirty implementation of this, which satisfies my own use case, which simply walks up the directory tree, from root, until `OS.File.stat` fails, or it comes to a non-directory file, and then defers to `OS.File.makeDir` with an appropriate `from` argument, but it would be nice to have this functionality builtin.
Comment 1•10 years ago
|
||
I'm almost sure that attempting to build a directory starting from the root can cause all sorts of unexpected side-effects in exotic configurations (e.g. nested mounts, Windows remote directories with remote authentication, etc.).
Option `from` was designed and implemented to encourage the developers to do something that will not cause such side-effects. In practice, while it is a little verbose, it works nicely, so unless you have a compelling reason to change its behavior, I am tempted to keep it.
Reporter | ||
Comment 2•10 years ago
|
||
It seems unlikely to cause side-effects to me, even given exotic configurations. Essentially the only difference will be walking up the directory tree until we find a component which does not exist, which I think should be expected to behave reasonably.
This is also a very common feature. `mkdir -p` is used extensively by *nix scripts, and even our own `nsILocalFile.create` implements this.
As for the use cases, it's hard to come up with a concrete example. I need it for a function which is given a path, and needs to create the directory, which is sometimes a child of TmpD, and sometimes in an arbitrary user-configurable location. The only way I can give it a `from` parameter is to have the caller pass it (which, in the case of the user-configurable location is infeasible), or to walk the directory tree myself.
I really don't like either of these solutions, and I don't think every caller should be expected to do it for such a common operation.
Comment 3•10 years ago
|
||
Just because nsILocalFile does it and mkdir does it doesn't mean that it will work nicely under Windows :)
More seriously, each access to a file/directory under Windows can lead to a big amount of sophisticated security checks, which may in turn require network calls, which also means that a network creation on a local disk could theoretically fail because of a network issue. I'm not comfortable encouraging this solution in a library as low-level as OS.File.
I'll try and think if I can find a nice solution.
@(In reply to Kris Maglione [:kmag] from comment #2)
> It seems unlikely to cause side-effects to me, even given exotic
> configurations. Essentially the only difference will be walking up the
> directory tree until we find a component which does not exist, which I think
> should be expected to behave reasonably.
>
> This is also a very common feature. `mkdir -p` is used extensively by *nix
> scripts, and even our own `nsILocalFile.create` implements this.
>
> As for the use cases, it's hard to come up with a concrete example. I need
> it for a function which is given a path, and needs to create the directory,
> which is sometimes a child of TmpD, and sometimes in an arbitrary
> user-configurable location. The only way I can give it a `from` parameter is
> to have the caller pass it (which, in the case of the user-configurable
> location is infeasible), or to walk the directory tree myself.
>
> I really don't like either of these solutions, and I don't think every
> caller should be expected to do it for such a common operation.
Do you need this feature still? I just got the hang of writing promises I can write this real fast: https://gist.github.com/Noitidart/67a81d730ec53040189c#file-_ff-addon-snippet-osfile_makedir_bug934283-js-L47
That linked is not top down, its bottom up with from. But i can easily mod it to do existing from top down, and then makeDir recursively from that point.
Flags: needinfo?(kmaglione+bmo)
Updated•7 years ago
|
Flags: needinfo?(kmaglione+bmo)
Comment 6•3 years ago
|
||
Mass closure: OSFIle is being replaced with IOUtils and PathUtils. If you think this bug was closed in error, please re-open.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Updated•1 years ago
|
Product: Toolkit → Toolkit Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•