Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the ability to read and modify file/directory permissions to dart:io #15078

Open
nex3 opened this issue Nov 14, 2013 · 17 comments
Open

Add the ability to read and modify file/directory permissions to dart:io #15078

nex3 opened this issue Nov 14, 2013 · 17 comments
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. library-io P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug

Comments

@nex3
Copy link
Member

nex3 commented Nov 14, 2013

Currently Dart provides no access to filesystem permissions at all. It should do so.

@nex3
Copy link
Member Author

nex3 commented Nov 14, 2013

Marked this as blocking #8101.

@andersjohnsen
Copy link

There is access to file-system permission in:

  FileStat.stat(path).then((stat) {
    print(stat.mode.toRadixString(8)); // Permission is mapped as octets
    print(stat.modeString());
  });

There are no way to set these, as of now.

@andersjohnsen
Copy link

Issue #1834 has been merged into this issue.


cc @sgjesse.
cc @madsager.

@kevmoo
Copy link
Member

kevmoo commented May 14, 2014

Removed Area-IO label.
Added Library-IO, Area-Library labels.

@DartBot
Copy link

DartBot commented Jan 7, 2015

This comment was originally written by @seaneagan


We also need to be able to access the current process uid and gid and FileStat uid and gid to compare them to each other to determine the process' permissions to that file/directory. Is that part of this bug, or is a separate one needed? I think it may even be possible to support it in windows, see:

baudehlo/node-fs-ext#27

@DartBot
Copy link

DartBot commented Jan 9, 2015

This comment was originally written by @seaneagan


File permission related bugs: issue #22036, issue #22037

@sgjesse
Copy link
Contributor

sgjesse commented Mar 24, 2015

Removed Type-Defect label.
Added Type-Enhancement label.

@tvolkert
Copy link
Contributor

It'd be good to add this. Having to call out to Process.run() is clunky.

@ghost ghost assigned sortie Sep 10, 2019
@ghost
Copy link

ghost commented Sep 10, 2019

Jonas, I think you're the current owner of dart:io?
Can you comment on whether it's feasible to add this?

@ghost ghost added the P2 A bug or feature request we're likely to work on label Sep 10, 2019
@ghost
Copy link

ghost commented Nov 14, 2019

Ping @sortie

@sortie
Copy link
Contributor

sortie commented Nov 14, 2019

@cskau-g This issue dropped out of my inbox and I forgot about it. Sorry about that.

It's easy enough to come up with a design that can a set Unix style permissions with chmod(2), much like what FileStat.mode currently exposes. However, dart:io works on both Unix and Windows, and generally avoids being designed too specifically for a particular operating system. Windows filesystem permissions are very different from Unix style permissions. Implementing Unix style permissions on Windows isn't really possible. It doesn't have the execute bit and groups work differently.

Indeed that's just file permissions, there's also the owner and group of files, and the complex ACLs supported by Windows, plus the ability to set the modified times of the file, and so on. A proper solution would be to have a full API for these actions. It may need to be different depending on the operating system. I think something like this would be worthwhile and would enhance Dart as a serve side language.

The problem you're trying to solve is just marking a file as executable, a concept that only exists on Unix. Running Process.run("chmod", ["-x", "--", file]) is a bit clunky, yes, but it's small and doable. I don't want to rush a special case API for just that but I'd rather like to look into a full API for filesystem operations.

@ghost
Copy link

ghost commented Mar 23, 2020

We also need to be able to access the current process uid and gid and FileStat uid and gid to compare them to each other to determine the process' permissions to that file/directory.

@sortie Yes, we need this.

vHanda added a commit to GitJournal/dart-git that referenced this issue Apr 29, 2020
@Timmmm
Copy link

Timmmm commented Jul 1, 2020

Running Process.run("chmod", ["-x", "--", file]) is a bit clunky, yes, but it's small and doable.

Calling out to system() isn't just "a bit clunky" - it's fragile and insecure. Case in point, this compiles fine but fails at runtime. -- isn't a valid argument. "What if your file is called -x though?" I hear you ask. Well exactly.

@vHanda
Copy link

vHanda commented Jun 28, 2021

I really need this for [dart-git]. Is there anyway to bump the priority of this? Or at least break it down into smaller tasks, which I can try to tackle?

I can use the chmod hack on systems which have chmod, but that's a small subset.

@mraleph
Copy link
Member

mraleph commented Jun 28, 2021

@vHanda there are no plans to implement this any time soon. You should simply use FFI to bind to whatever underlying API the OS provides.

vHanda added a commit to GitJournal/dart-git that referenced this issue Jun 29, 2021
Dart unfortunately doesn't provide a way, however this convenient
package 'os' allows us to change it via FFI.

Related to dart-lang/sdk#15078
@vHanda
Copy link

vHanda commented Dec 9, 2021

For anyone else facing the same problem, checkout https://pub.dev/packages/posix

@stephane-archer
Copy link

import 'package:posix/posix.dart';
chmod(file.path, permissions);

I'm glad people fix it while Google is still figuring out what permissions are

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. library-io P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests