feature request: fs.softDelete or the like?

[Pomax]

Both Windows and MacOS has "safe" delete APIs for moving things to, respectively, the Recycle Bin and the Trash, from where files can be undeleted again - it would be super nice if fs-extra had a way to unlink files in a way that made them end up in those locations, rather than outright unlinking.

And I honestly have no idea what a good name for that would be, softDelete is kind of weird, maybe safeUnlink? trash? (there is a trash package already named that, so... maybe that? Though I couldn't get it to actually delete files to the recycle bin on the machine I tested it on)

[RyanZim]

Yeah, https://github.com/sindresorhus/trash should be the package for that. If you're having issues with it, might try opening an issue there. Not sure if it's within scope for fs-extra to include that functionality, though.

[Pomax]

Maybe, but let's be fair: the whole reason we have fs-extra at all is because "[JP] got tired of including mkdirp, rimraf, and ncp in most of my projects.", so adding trash as a safe unlink for the vast majority of developers is probably not really out of scope? That feels like it should fit right in.

[RyanZim]

@jprichardson @manidlou @JPeer264 what's your opinions here?

[RyanZim]

@jprichardson @manidlou @JPeer264 bump

[manidlou]

I am not completely sure but I feel like it is out of scope. For this, we probably need to have OS specific implementations. Also, I don't think we can achieve this without running some shell commands (if there is a way without using shell, I would love to know about it) and we all know that we don't deal with shell in this lib because of its security issues.

[Pomax]

what if you just wrap the https://github.com/sindresorhus/trash package, and expose its functions as part of fs-extra?

[idler8]

The functions of trash are too few. We should need a nodejs global file permission, similar to fs.lock() or fs.auth(), to restrict file deletion and modification to a certain secure directory, such as the same level or src folder.
Will you add this feature to this project? @RyanZim

[RyanZim]

@idler8 I'm not understanding what you're proposing?

[Pomax]

"being able to secure a directory" feels pretty out of scope for fs-extra, which as far as I understand it is a convenience package that lets you import one package, instead of always having to import rimraf, mkdirp, etc. because almost any project that works with the filesystem will end up relying on those.

[idler8]

If I run this code at the beginning of the scriptfs.lock('./');.
I will return an error when I run fs.unlink('../a.json')/fs.write('../a.json')
It will be handled correctly when I run fs.unlink('./b.json')
Until I run fs.lock (null) or fs.unlock ()
Can you understand what i mean @RyanZim

[idler8]

I have an immature idea

fs.lock = function(lockpath) {
	if (!lockpath && fs.unlink.lock) return (fs.unlink = fs.unlink.original);
	if (fs.unlink.lock) return (fs.unlink.lock = lockpath);
	var unlink = fs.unlink;
	fs.unlink = function(filepath, callback) {
		//Check filepath before running unlink
	};
	fs.unlink.lock = lockpath;
	fs.unlink.original = unlink;
};

[RyanZim]

Ah, I got your idea; basically a sandboxed filesystem. That's another whole level of complexity, and out of scope for fs-extra. Might make a great standalone package, though.