Bug #106081 for File-Path: RFE: enable file rewrite mode

Sat Jul 25 06:43:11 2015 RICHE [...] cpan.org - Ticket created

Subject:

RFE: enable file rewrite mode

From TODO: Investigate rm -p functionality (a linux thing). ======================= RICHE Note: most likely the original submitter meant "rm -P". Or possibly "mkdir -p". AFAIK, there is no such thing as "rm -p".

Wed Jul 29 22:07:14 2015 jkeenan [...] cpan.org - Correspondence added

On Sat Jul 25 06:43:11 2015, RICHE wrote: Show quoted text

> From TODO: > > Investigate rm -p functionality (a linux thing). > > ======================= > > RICHE Note: most likely the original submitter meant "rm -P". Or > possibly "mkdir -p". AFAIK, there is no such thing as "rm -p".

On Ubuntu 14.04: from 'man rm' ##### -r, -R, --recursive remove directories and their contents recursively ##### Don't rmtree and remove_tree do that already?

Wed Jul 29 22:07:14 2015 The RT System itself - Status changed from 'new' to 'open'

Fri Jul 31 06:25:16 2015 RICHE [...] cpan.org - Correspondence added

On Wed Jul 29 22:07:14 2015, JKEENAN wrote: Show quoted text

> On Sat Jul 25 06:43:11 2015, RICHE wrote:

> > From TODO: > > > > Investigate rm -p functionality (a linux thing). > > > > ======================= > > > > RICHE Note: most likely the original submitter meant "rm -P". Or > > possibly "mkdir -p". AFAIK, there is no such thing as "rm -p".

> > > On Ubuntu 14.04: from 'man rm' > > ##### > -r, -R, --recursive > remove directories and their contents recursively > ##### > > Don't rmtree and remove_tree do that already?

Hi Jim, I think this is more of a security feature if the person putting this in the original TODO meant -P. This triple rewrite before delete would make it so the original files that are being removed would be, in theory, completely unrecoverable from disk. Please see: https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html It might be worth socializing as a feature. Otherwise, the inevitable could occur, something like File::Path::Secure.

Sat Aug 01 02:28:05 2015 SREZIC [...] cpan.org - Correspondence added

On 2015-07-31 06:25:16, RICHE wrote: Show quoted text

> On Wed Jul 29 22:07:14 2015, JKEENAN wrote:

> > On Sat Jul 25 06:43:11 2015, RICHE wrote:

> > > From TODO: > > > > > > Investigate rm -p functionality (a linux thing). > > > > > > ======================= > > > > > > RICHE Note: most likely the original submitter meant "rm -P". Or > > > possibly "mkdir -p". AFAIK, there is no such thing as "rm -p".

> > > > > > On Ubuntu 14.04: from 'man rm' > > > > ##### > > -r, -R, --recursive > > remove directories and their contents recursively > > ##### > > > > Don't rmtree and remove_tree do that already?

> > Hi Jim, > > I think this is more of a security feature if the person putting this > in the original TODO meant -P. This triple rewrite before delete > would make it so the original files that are being removed would be, > in theory, completely unrecoverable from disk. > > Please see: > > https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html > > It might be worth socializing as a feature. Otherwise, the inevitable > could occur, something like File::Path::Secure.

FreeBSD's rm implements -P, but the manpage explicitly says that "The -P flag is not considered a security feature". See https://www.freebsd.org/cgi/man.cgi?query=rm for more details. So maybe, with today's modern filesystems and storage mediums, it's not worth to implement this option.

Sat Aug 01 06:50:15 2015 RICHE [...] cpan.org - Correspondence added

On Sat Aug 01 02:28:05 2015, SREZIC wrote: Show quoted text

> On 2015-07-31 06:25:16, RICHE wrote:

> > On Wed Jul 29 22:07:14 2015, JKEENAN wrote:

> > > On Sat Jul 25 06:43:11 2015, RICHE wrote:

> > > > From TODO: > > > > > > > > Investigate rm -p functionality (a linux thing). > > > > > > > > ======================= > > > > > > > > RICHE Note: most likely the original submitter meant "rm -P". Or > > > > possibly "mkdir -p". AFAIK, there is no such thing as "rm -p".

> > > > > > > > > On Ubuntu 14.04: from 'man rm' > > > > > > ##### > > > -r, -R, --recursive > > > remove directories and their contents recursively > > > ##### > > > > > > Don't rmtree and remove_tree do that already?

> > > > Hi Jim, > > > > I think this is more of a security feature if the person putting this > > in the original TODO meant -P. This triple rewrite before delete > > would make it so the original files that are being removed would be, > > in theory, completely unrecoverable from disk. > > > > Please see: > > > > https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html > > > > It might be worth socializing as a feature. Otherwise, the > > inevitable > > could occur, something like File::Path::Secure.

> > FreeBSD's rm implements -P, but the manpage explicitly says that "The > -P flag is not considered a security feature". See > https://www.freebsd.org/cgi/man.cgi?query=rm for more details. So > maybe, with today's modern filesystems and storage mediums, it's not > worth to implement this option.

Fair enough. The original intent of the -P flag was to implement that specification, but the implementation that's realized in rm has some limitations. Journaled filesystems are similar to old school backups (or even things like Netapp ghosting): you don't get rid of the files in the snapshot unless you delete the whole snapshot. That's the background argument for the BUGS section relating to journaled file systems. In effect, they're saying (without saying) if you ever backed up the filesystem then -P still fails as a feature. That's pretty weak. It _would_ be interesting to figure out if this specification is relevant at all to SSDs. If it's not, then I would say to forget this 'feature'. SSDs are basically taking over the PC as well as the datacenter.

Sat Aug 01 07:59:32 2015 jkeenan [...] cpan.org - Correspondence added

On Sat Aug 01 02:28:05 2015, SREZIC wrote: Show quoted text

> On 2015-07-31 06:25:16, RICHE wrote:

> > On Wed Jul 29 22:07:14 2015, JKEENAN wrote:

> > > On Sat Jul 25 06:43:11 2015, RICHE wrote:

> > > > From TODO: > > > > > > > > Investigate rm -p functionality (a linux thing). > > > > > > > > ======================= > > > > > > > > RICHE Note: most likely the original submitter meant "rm -P". Or > > > > possibly "mkdir -p". AFAIK, there is no such thing as "rm -p".

> > > > > > > > > On Ubuntu 14.04: from 'man rm' > > > > > > ##### > > > -r, -R, --recursive > > > remove directories and their contents recursively > > > ##### > > > > > > Don't rmtree and remove_tree do that already?

> > > > Hi Jim, > > > > I think this is more of a security feature if the person putting this > > in the original TODO meant -P. This triple rewrite before delete > > would make it so the original files that are being removed would be, > > in theory, completely unrecoverable from disk. > > > > Please see: > > > > https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html > > > > It might be worth socializing as a feature. Otherwise, the > > inevitable > > could occur, something like File::Path::Secure.

> > FreeBSD's rm implements -P, but the manpage explicitly says that "The > -P flag is not considered a security feature". See > https://www.freebsd.org/cgi/man.cgi?query=rm for more details. So > maybe, with today's modern filesystems and storage mediums, it's not > worth to implement this option.

Slaven, thanks for that link. Given that this option is (a) very OS-specific; (b) documented to be of limited value even on an OS where it's implemented; and (c) would constitute a significant extension of what File::Path's scope has always been; I think we should simply reject this feature request. Anyone who really wants it should try to implement it in a separate CPAN package and be prepared to maintain it there. Thank you very much. Jim Keenan

Wed Aug 05 15:10:51 2015 RICHE [...] cpan.org - Correspondence added

Show quoted text

> Slaven, thanks for that link. Given that this option is (a) very OS- > specific; (b) documented to be of limited value even on an OS where > it's implemented; and (c) would constitute a significant extension of > what File::Path's scope has always been; I think we should simply > reject this feature request. Anyone who really wants it should try to > implement it in a separate CPAN package and be prepared to maintain it > there. > > Thank you very much. > Jim Keenan

I'll second that. While I feel the RFE has some merit, it extends the scope of File::Path too much. I think a "nice to have" would be to make it easy for people to extend File::Path in a way so they can do something like a "before remove action" and "after remove action" which would in turn make it so people didn't have to copy paste the routine or roll their own new implementation of the routine.

Wed Aug 05 15:10:52 2015 RICHE [...] cpan.org - Status changed from 'open' to 'rejected'