chmod() missing Julia-side

[staticfloat]

Alongside #7573, it seems that we do indeed have a chmod within libuv, but it's not wrapped in Julia at all. We should probably support that so that if we somehow manage to create a read-only file on Windows, we can make it writable so that we can delete it.

[tkelman]

Quoting from https://github.com/joyent/libuv/blob/8d11aacb79472009189c35e8953d0fa316bfd202/src/win/fs.c#L867-L885:

  /* Todo: st_mode should probably always be 0666 for everyone. We might also
   * want to report 0777 if the file is a .exe or a directory.
   *
   * Currently it's based on whether the 'readonly' attribute is set, which
   * makes little sense because the semantics are so different: the 'read-only'
   * flag is just a way for a user to protect against accidental deleteion, and
   * serves no security purpose. Windows uses ACLs for that.
   *
   * Also people now use uv_fs_chmod() to take away the writable bit for good
   * reasons. Windows however just makes the file read-only, which makes it
   * impossible to delete the file afterwards, since read-only files can't be
   * deleted.
   *
   * IOW it's all just a clusterfuck and we should think of something that
   * makes slighty more sense.
   *
   * And uv_fs_chmod should probably just fail on windows or be a total no-op.
   * There's nothing sensible it can do anyway.
   */

Hmm.

[jakebolewski]

Wow I didn't realize things were this broken.

[tkelman]

I can do this one. Does it need a jl_fs_chmod wrapper in C, or should it be a straight ccall to libuv the way open is done?

[tkelman]

Question: does anybody want/use/understand = or X flags in chmod? I have chmod(mode::Integer, p::String) more or less working, but chmod(mode::String, p::String) is more code and I'm not sure I can correctly do anything more complicated than [ugoa][+-][rwxst]. How complete an implementation should we aim for?

[jakebolewski]

chmod + string support I feel is a non-essential feature. This could always be added later. I vote keep it simple for the time being so this gets merged soon.

[StefanKarpinski]

Interactively, I use X with recursive chmod all the time. Not sure if it's that useful programmatically.

[jakebolewski]

@tkelman will chmod at least let us delete readonly files on Windows or is this going to be broken? I thought that the above comment was more about file permissions.

[tkelman]

@jakebolewski in my testing switching the 0o200 bit is able to turn on and off the read-only property, so I think it'll be good enough. I'll submit a numeric-only chmod PR in a couple minutes.

[tkelman]

Crap. Python argument order chmod(path, mode), or command line order chmod(mode, path) ?

[jakebolewski]

+1 for python order

[tkelman]

Man, why these things gotta be nonstandard.

mode, path

• coreutils https://www.gnu.org/software/coreutils/manual/html_node/chmod-invocation.html
• Ruby http://www.ruby-doc.org/core-2.1.2/File.html#method-c-chmod
• Perl http://perldoc.perl.org/functions/chmod.html

path, mode

• POSIX C http://pubs.opengroup.org/onlinepubs/009695399/functions/chmod.html
• Python https://docs.python.org/2/library/os.html#os.chmod
• R http://stat.ethz.ch/R-manual/R-devel/library/base/html/files2.html
• Node http://nodejs.org/api/fs.html#fs_fs_chmod_path_mode_callback

[elextr]

(mode, path...)?

[tkelman]

We could also do (paths... ; mode = mode) but for a first cut I was only going to do a single file at a time. Most of the other functions in base/fs.jl don't have varargs versions yet.

[StefanKarpinski]

Most of our path and file stuff follows Python, so I'm inclined to follow Python here too.