Skip Menu |
 

This queue is for tickets about the File-Path CPAN distribution.

Report information
The Basics
Id: 106081
Status: rejected
Priority: 0/
Queue: File-Path

People
Owner: Nobody in particular
Requestors: RICHE [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: RFE: enable file rewrite mode
Download (untitled) / with headers
text/plain 217b
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".
Download (untitled) / with headers
text/plain 458b
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?
Download (untitled) / with headers
text/plain 997b
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.
Download (untitled) / with headers
text/plain 1.3k
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.
Download (untitled) / with headers
text/plain 2.2k
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.
Download (untitled) / with headers
text/plain 1.9k
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
Download (untitled) / with headers
text/plain 881b
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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.