We already have the following methods

  delete
  deleteSync
  exists
  existsSync
  rename
  renameSync
  stat
  statSync

When we moved delete and deleteSync to FileSystemEntity, we changed the behavior of delete with recursive true to always delete no matter the type of the receiver. So now you can do:

 void deleteIfPresent(String path) {
   try {
     var dir = new Directory(path);
     dir.deleteSync(recursive: true);
   } catch (e) {
     print('Error while deleting $path: $e');
   }
 }

Is this what you are looking for?

Added NeedsInfo label.

This comment was originally written by @seaneagan

issue #12245 is related.

Is recursive ignored for Files and Links which represent Files?

I think having the following constructor would help:

  FileSystemEntity(String path);

also could add a "onAbsent" arg to delete(Sync):

void deleteSync({bool recursive: false, var onAbsent});

Then you could do:

deleteIfPresent(String path) =>
    new FileSystemEntity(path).deleteSync(recursive: true, onAbsent: () {});

and to delete Directory contents:

deleteDirectoryContents(Directory directory) =>
    directory.listSync().forEach((fse) => fse.deleteSync(recursive: true));

Interesting, I didn't know that Directory.delete did what I wanted =).

However, I agree with Sean that having a constructor that treats a path just as a FSE would be great. Without it, my main concern is that doing:

    new Directory(path).deleteSync(recursive: true);

Feels like I'm assuming that 'path' is a directory and it should fail if it's not. Instead, the following:

    new FileSystemEntity(path).deleteSync(recursive: true, followSymlinks: false);

expresses my intent better: I don't care what 'path' is, but I want to delete it.

Added Triaged label.

The current constructors for File, Directory and Link does not initiate any IO - they just create an object with a path in it. There is not check whether this path exists, and the File, Directory and Link instance can be used to create the actual file system object.

The FileSystemEntity class is abstract so if we add a factory constructor to it taking a path it will need to check the type of the the actual file system object to determine whether to create an instance of File, Directory or Link. If there is no file system object with the given path this is not possible and constructor will have to fail.

Having a constructor on FileSystemEntity doen not really work well with the subclassing into File, Directory and Link.

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

This comment was originally written by @seaneagan

The FileSystemEntity constructor could return an instance of a class whose
methods each determine whether it is a file, directory, or link and
delegate accordingly. The only extra failure case from this I can think of
would be create(Sync) when the FSE doesn't already exist:

new FileSystemEntity(path).createSync(); // Fails if path doesn't exist.

Added this to the Later milestone.
Removed Priority-Unassigned label.
Added Priority-Low label.

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

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

Removed Oldschool-Milestone-Later label.