Prototype of Files service.

services/files/directory.mojom

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+module mojo.files;
+
+import "services/files/file.mojom";
+import "services/files/types.mojom";
+
+// TODO(vtl): paths may be relative; should they allowed to be absolute?
+// (currently not)

[qsr, 2015/03/03 11:56:44]

Can you specify somewhere that all |path| in the different operations are
relatives to "this" directory.

[viettrungluu, 2015/03/03 18:50:35]

Done.

+
+// TODO(vtl): Write comments.
+interface Directory {
+  // Operations about "this" |Directory|:
+
+  // TODO(vtl): Should we have a "close" method?
+
+  // Reads the contents of this directory.
+  // TODO(vtl): Clarify error codes versus |directory_contents|.
+  Read() => (Error error, array<DirectoryEntry>? directory_contents);
+
+  // Gets information about this directory. On success, |file_information| is
+  // non-null and will contain this information.
+  Stat() => (Error error, FileInformation? file_information);
+
+  // Updates this directory's atime and/or mtime to the time specified by
+  // |atime| (or |mtime|, respectively), which may also indicate "now". If
+  // |atime| or |mtime| is null, then the corresponding time is not modified.
+  Touch(TimespecOrNow? atime, TimespecOrNow? mtime) => (Error error);
+
+  // Operations *in* "this" |Directory|:
+
+  // Opens the file specified by |path| with the given |open_flags|. |file| is
+  // optional, mainly for consistency with |OpenDirectory()| (but may be useful,
+  // together with |kOpenFlagCreate|, for "touching" a file).
+  OpenFile(string path, File&? file, uint32 open_flags)
+      => (Error error);
+
+  // Opens the directory specified by |path|. |directory| is optional, so that
+  // this may be used as a simple "mkdir()" with |kOpenFlagCreate|.

[qsr, 2015/03/03 11:56:44]

I guess "." is a valid path? Is this the way to duplicate a directory to be able
to send it to another application?

[viettrungluu, 2015/03/03 18:50:35]

That's a good point. Possibly Directory should have Dup()/Reopen(), like File.
(Added TODO.)

+  OpenDirectory(string path,
+                Directory&? directory,
+                uint32 open_flags) => (Error error);
+
+  // Renames/moves the file/directory given by |path| to |new_path|.
+  Rename(string path, string new_path) => (Error error);
+
+  // Deletes the given path, which may be a file or a directory (see
+  // |kDeleteFlag...| for details).
+  Delete(string path, uint32 delete_flags) => (Error error);
+
+  // TODO(vtl): directory "streaming"?
+  // TODO(vtl): "make root" (i.e., prevent cd-ing, etc., to parent); note that
+  // this would require a much more complicated implementation (e.g., it needs
+  // to be "inherited" by OpenDirectory(), and the enforcement needs to be valid
+  // even if the opened directory is subsequently moved -- e.g., closer to the
+  // "root")

[qsr, 2015/03/03 11:56:44]

Agreed on letting this as a TODO, but shouldn't this be the default (or even the
only mode of operation)? I don't think we should ever accept path that would get
out of the current directly. You use Directories to have a root, and each time
you cd, you change the root, if you want to have access to more, you keep the
original root.

[viettrungluu, 2015/03/03 18:50:35]

Being unable to chdir() out would make it difficult/impossible for people to
implement POSIX-style current working directories (which may even be
per-thread).

(To imitate it, an app would have to just keep the root Directory, and then keep
track of the CWD as a path. But this isn't a faithful imitation: "cd foo; mkdir
../bar; mv ../foo ../bar; cd .." probably wouldn't work right -- especially if
the mv were done by someone else.)

[qsr, 2015/03/04 15:10:19]

 I see. But then, do you have any idea how to correctly implement rooting a
directory? If I have a rooted directory, I go one down to a sub-directory (so
the directory I opened is not rooted anymore, but it is expected I cannot go up
more than once), then this directory is moved outside of its parent. How would
we make sure that you cannot go up to some place you never were supposed to be
able to access?

 If we prevent any access to anything over the current directory, I think we do
not have this kind of problems.

+  // TODO(vtl): Add a "watch"?
+};