Comments on: Should We Abolish User Access to rm? http://www.linux-mag.com/id/7950/ Open Source, Open Standards Sat, 05 Oct 2013 13:48:18 +0000 hourly 1 http://wordpress.org/?v=3.1 By: Anthony http://www.linux-mag.com/id/7950/#comment-1088869 Anthony Wed, 31 Jul 2013 13:15:54 +0000 http://www.linux-mag.com/id/7950/#comment-1088869 As this has been a need since virtually the beginning of "rm", I think it should be an option, and am actually surprised it's not already. -m, --move [directory] move the file to directory instead of unlinking As this has been a need since virtually the beginning of “rm”, I think it should be an option, and am actually surprised it’s not already.

-m, –move [directory] move the file to directory instead of unlinking

]]> By: matt http://www.linux-mag.com/id/7950/#comment-1087065 matt Tue, 30 Jul 2013 22:00:35 +0000 http://www.linux-mag.com/id/7950/#comment-1087065 solved problem, ask Rob Pike http://man.cat-v.org/plan_9/1/yesterday solved problem, ask Rob Pike

http://man.cat-v.org/plan_9/1/yesterday

]]> By: anon http://www.linux-mag.com/id/7950/#comment-1086789 anon Tue, 30 Jul 2013 19:42:17 +0000 http://www.linux-mag.com/id/7950/#comment-1086789 >> However, what concerned people was that you have to take frequent snapshots so that you can capture changes. The implication is that you need space to hold the snapshot (which varies) and you need to “freeze” the file system while taking the snapshot Maybe time for you to read up on how this actually works; I think you misunderstand the technology. For example, read about how DataONTAP deduplicates data, and how that mechanism is used to provide live snapshots that use very, VERY little space. Much less than you would think. Another poster said about 10%. my experience is 10-15% space of the FS is used to store changes on a fairly active filesystem going 4 weeks. ZFS is very similar. >> However, what concerned people was that you have to take frequent snapshots so that you can capture changes. The implication is that you need space to hold the snapshot (which varies) and you need to “freeze” the file system while taking the snapshot

Maybe time for you to read up on how this actually works; I think you misunderstand the technology. For example, read about how DataONTAP deduplicates data, and how that mechanism is used to provide live snapshots that use very, VERY little space. Much less than you would think. Another poster said about 10%. my experience is 10-15% space of the FS is used to store changes on a fairly active filesystem going 4 weeks. ZFS is very similar.

]]> By: MeraX http://www.linux-mag.com/id/7950/#comment-1086777 MeraX Tue, 30 Jul 2013 19:37:39 +0000 http://www.linux-mag.com/id/7950/#comment-1086777 Have a look at this rm compatible script for `trash': http://www.daniel-rudolf.de/bash/rmtrash # SHORT DESCRIPTION: # Put files (and directories) in trash using the `trash' command in a way # that is, otherwise as `trash' itself, compatible to GNUs `rm'. # # # DEPENDENCIES: # - `trash', provided by the package `trash-cli' and the same for rmdir: http://www.daniel-rudolf.de/bash/rmdirtrash Have a look at this rm compatible script for `trash’:
http://www.daniel-rudolf.de/bash/rmtrash
# SHORT DESCRIPTION:
# Put files (and directories) in trash using the `trash’ command in a way
# that is, otherwise as `trash’ itself, compatible to GNUs `rm’.
#
#
# DEPENDENCIES:
# – `trash’, provided by the package `trash-cli’

and the same for rmdir:
http://www.daniel-rudolf.de/bash/rmdirtrash

]]> By: Online Casino http://www.linux-mag.com/id/7950/#comment-888655 Online Casino Sat, 20 Apr 2013 13:09:43 +0000 http://www.linux-mag.com/id/7950/#comment-888655 It's very simple to find out any topic on net as compared to textbooks, as I found this post at this web site. It’s very simple to find out any topic on net as compared to textbooks, as I found this post at this web site.

]]> By: visnotjl http://www.linux-mag.com/id/7950/#comment-165001 visnotjl Wed, 14 Mar 2012 14:26:41 +0000 http://www.linux-mag.com/id/7950/#comment-165001 why shouldn't we remove brain too, in order to prevent people from being stupid ? why shouldn’t we remove brain too, in order to prevent people from being stupid ?

]]> By: Noneya http://www.linux-mag.com/id/7950/#comment-30295 Noneya Wed, 09 Nov 2011 13:01:22 +0000 http://www.linux-mag.com/id/7950/#comment-30295 That would mean that rm would still have to be aliased to send the file to a temporary place since rm in it's raw form destroys the inode from the table and completely removes data. That would mean that rm would still have to be aliased to send the file to a temporary place since rm in it’s raw form destroys the inode from the table and completely removes data.

]]> By: hyattdj http://www.linux-mag.com/id/7950/#comment-10040 hyattdj Tue, 04 Oct 2011 18:34:57 +0000 http://www.linux-mag.com/id/7950/#comment-10040 how about an old school solution, alias the users you are worried about to move the files from their location to a scratch location. Which has a cleanup routine that removes files after 3 days. Remove the alias from application users or trusted users or just run /usr/bin/rm to truely remove files. how about an old school solution, alias the users you are worried about to move the files from their location to a scratch location. Which has a cleanup routine that removes files after 3 days.
Remove the alias from application users or trusted users or just run /usr/bin/rm to truely remove files.

]]> By: krummenhacker http://www.linux-mag.com/id/7950/#comment-9529 krummenhacker Mon, 23 May 2011 14:16:39 +0000 http://www.linux-mag.com/id/7950/#comment-9529 There is one UNIX version that contains such a incremental backup tool. On this system, recovering deleted data is straightforward. The tool name is TimeMachine, the UNIX version is named OS X and is made by that company who has a partly eated fruit for its logo, Apple. Time Machine saved my day more than once. There is one UNIX version that contains such a incremental backup tool. On this system, recovering deleted data is straightforward. The tool name is TimeMachine, the UNIX version is named OS X and is made by that company who has a partly eated fruit for its logo, Apple. Time Machine saved my day more than once.

]]> By: John Wiersba http://www.linux-mag.com/id/7950/#comment-8971 John Wiersba Mon, 21 Feb 2011 23:29:56 +0000 http://www.linux-mag.com/id/7950/#comment-8971 I personally use an alias to a simple script. The script checks the number of command line args: if 1, then it calls rm; if > 1, then it prints the args and prompts the user before calling rm. That way if a wildcard expression accidentally matches more than one file, I'll catch it. I personally use an alias to a simple script. The script checks the number of command line args: if 1, then it calls rm; if > 1, then it prints the args and prompts the user before calling rm. That way if a wildcard expression accidentally matches more than one file, I’ll catch it.

]]> By: doj http://www.linux-mag.com/id/7950/#comment-8862 doj Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7950/#comment-8862 <p>try http://pages.stern.nyu.edu/~marriaga/software/libtrash/ to make the effects of unlink and overwrites reversible. Or you could try<br /> Google's https://code.google.com/p/safe-rm/ </p> try http://pages.stern.nyu.edu/~marriaga/software/libtrash/ to make the effects of unlink and overwrites reversible. Or you could try
Google’s https://code.google.com/p/safe-rm/

]]> By: tangle http://www.linux-mag.com/id/7950/#comment-8863 tangle Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7950/#comment-8863 <p>Just a thought, but if a user can not delete data that is no longer needed, would you not have a storage problem eventually. You know you always have a pack rat or two that use a tremendous amount of storage. Now everyone will be a pack rat. Accidents do happen but people also need to realize that you reap what you sow and they need to pay attention or wait. </p> <p>I have had to recover deleted file a few times. I never had a problem with someone complaining about the time it took to recover a file. They where always appreciative when the file could be recovered. </p> <p>Data recovery is part of an admins job. As is eating user complaints to an extent. Both suck, but then again it is a job. </p> Just a thought, but if a user can not delete data that is no longer needed, would you not have a storage problem eventually. You know you always have a pack rat or two that use a tremendous amount of storage. Now everyone will be a pack rat. Accidents do happen but people also need to realize that you reap what you sow and they need to pay attention or wait.

I have had to recover deleted file a few times. I never had a problem with someone complaining about the time it took to recover a file. They where always appreciative when the file could be recovered.

Data recovery is part of an admins job. As is eating user complaints to an extent. Both suck, but then again it is a job.

]]> By: llohman http://www.linux-mag.com/id/7950/#comment-8864 llohman Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7950/#comment-8864 <p>The solution to this problem comes from planning and foresight. Deploying any system on which Users will store their data means that 'rm' is going to become a problem for support staff. Personally, I would recommend using LVM and snapshots to preserve the integrity of the data on the system - this in addition to any normal backup scheme.</p> <p>Once one is aware of the 'normal' rate of change (additions/deletions/) in the data on the system, the size of the snapshot volume can be estimated, allocated, and put to good use.</p> <p>And the Users data is protected. </p> The solution to this problem comes from planning and foresight. Deploying any system on which Users will store their data means that ‘rm’ is going to become a problem for support staff. Personally, I would recommend using LVM and snapshots to preserve the integrity of the data on the system – this in addition to any normal backup scheme.

Once one is aware of the ‘normal’ rate of change (additions/deletions/) in the data on the system, the size of the snapshot volume can be estimated, allocated, and put to good use.

And the Users data is protected.

]]> By: tbuskey http://www.linux-mag.com/id/7950/#comment-8865 tbuskey Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7950/#comment-8865 <p>You left out one solution. Snapshots. A NetApp does them. So does ZFS. I think BTRFS will also.</p> <p>A NetApp does a snapshot every 15 minutes, every hour, every day, every week, every month and keeps them for 1 hr, 1 day, 7 days, 5 weeks, 1 year. It takes up about 10% of the storage.</p> <p>I ran a site with 100 users for 5 years and never had to restore from tape.</p> <p>Policy and education are key too. Some users thing backups are archives. Backups are to replace the current data with the most recent if something goes wrong. Archives are to go back to a specific point in time. </p> You left out one solution. Snapshots. A NetApp does them. So does ZFS. I think BTRFS will also.

A NetApp does a snapshot every 15 minutes, every hour, every day, every week, every month and keeps them for 1 hr, 1 day, 7 days, 5 weeks, 1 year. It takes up about 10% of the storage.

I ran a site with 100 users for 5 years and never had to restore from tape.

Policy and education are key too. Some users thing backups are archives. Backups are to replace the current data with the most recent if something goes wrong. Archives are to go back to a specific point in time.

]]> By: jp http://www.linux-mag.com/id/7950/#comment-8866 jp Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7950/#comment-8866 <p>Here are a few things worth saying -- about traditional filesystems, at least:</p> <ul> <li>A file can have multiple links, hard or symbolic. A front-end to <em>rm</em> might check for these and prompt the user. (A user who doesn't understand what <em>rm</em> does may not think of links either.) Moving a file can leave broken symlinks and/or other hard links behind.</li> <li>If your front-end moves a file to a different filesystem, but it doesn't move all hard links, the file data will simply be copied to the new filesystem, and the old data will stay on the original filesystem (through the file's other hard links).</li> <li>One big problem with replacing <em>/bin/rm</em> itself is that shell scripts often use <em>rm</em> and expect it to work normally. Modifying <em>rm</em> to add "are you sure?" prompts, informative outputs, etc., can break shell scripts that users have had for years... especially scripts run non-interactively from places like a <em>cron</em> job.</li> <li>Adding a shell alias for <em>rm</em> generally only affects users who run <em>rm</em> from the command line... and doesn't affect scripts or other system programs. This is often a good thing.</li> </ul> <p>Jerry </p> Here are a few things worth saying — about traditional filesystems, at least:

  • A file can have multiple links, hard or symbolic. A front-end to rm might check for these and prompt the user. (A user who doesn’t understand what rm does may not think of links either.) Moving a file can leave broken symlinks and/or other hard links behind.
  • If your front-end moves a file to a different filesystem, but it doesn’t move all hard links, the file data will simply be copied to the new filesystem, and the old data will stay on the original filesystem (through the file’s other hard links).
  • One big problem with replacing /bin/rm itself is that shell scripts often use rm and expect it to work normally. Modifying rm to add “are you sure?” prompts, informative outputs, etc., can break shell scripts that users have had for years… especially scripts run non-interactively from places like a cron job.
  • Adding a shell alias for rm generally only affects users who run rm from the command line… and doesn’t affect scripts or other system programs. This is often a good thing.

Jerry

]]> By: pbock http://www.linux-mag.com/id/7950/#comment-8867 pbock Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7950/#comment-8867 <p>I think it is foolish for admins to rm rm. It seems the underlying complaint here is that the admins want to free themselves from the burden of recovering lost files. So give the users the ability to recover the files themselves. One way to do this is to give them a versioning file system. So that they can go back and look at any version of file they want. Delete, wouldn't entirely remove the file, only remove it from immediate view. </p> <p>Taking away a users ability to rm a file would be like banning cars because there are a few car accidents. Cars are obviously very useful. It sounds like the admins don't want to be in the collision repair business. That's fine. </p> <p>I have been having fun experimenting with new filesystem ideas by using webdav to build psuedo filesystems using web-development tools like mysql and php. </p> <p>How many articles, or versions of articles, have been lost from wikipedia? How hard is it for anyone to recover an article from a previous date? </p> I think it is foolish for admins to rm rm. It seems the underlying complaint here is that the admins want to free themselves from the burden of recovering lost files. So give the users the ability to recover the files themselves. One way to do this is to give them a versioning file system. So that they can go back and look at any version of file they want. Delete, wouldn’t entirely remove the file, only remove it from immediate view.

Taking away a users ability to rm a file would be like banning cars because there are a few car accidents. Cars are obviously very useful. It sounds like the admins don’t want to be in the collision repair business. That’s fine.

I have been having fun experimenting with new filesystem ideas by using webdav to build psuedo filesystems using web-development tools like mysql and php.

How many articles, or versions of articles, have been lost from wikipedia? How hard is it for anyone to recover an article from a previous date?

]]> By: cdsteinkuehler http://www.linux-mag.com/id/7950/#comment-8868 cdsteinkuehler Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7950/#comment-8868 <p>I still occasionally miss the old Netware 3.1 days. Deleted files were kept around automatically, and you could easily recover several previous versions of a file, no matter /how/ they were deleted (as long as the volume wasn't too full, causing the stale files to be re-allocated for free space). Saved my bacon many a time... </p> I still occasionally miss the old Netware 3.1 days. Deleted files were kept around automatically, and you could easily recover several previous versions of a file, no matter /how/ they were deleted (as long as the volume wasn’t too full, causing the stale files to be re-allocated for free space). Saved my bacon many a time…

]]> By: mytemuslim http://www.linux-mag.com/id/7950/#comment-8869 mytemuslim Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7950/#comment-8869 <p>I actually like the idea of aliasing the rm command and moving the records to a temporary directory. Allowing cron to delete the job at specific intervals would mean the data would be caught on backups. Depending on policies you could be able to restore data for 3-6 months even more. Obviously not a strong solution for every industry since there would be legal caveats concerning certain types of retention. </p> I actually like the idea of aliasing the rm command and moving the records to a temporary directory. Allowing cron to delete the job at specific intervals would mean the data would be caught on backups. Depending on policies you could be able to restore data for 3-6 months even more. Obviously not a strong solution for every industry since there would be legal caveats concerning certain types of retention.

]]> By: radleym http://www.linux-mag.com/id/7950/#comment-8870 radleym Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7950/#comment-8870 <p>A google search showed several links to undelete programs/procedures for various filesystems. The ideal solution would be a user undelete command, no? </p> A google search showed several links to undelete programs/procedures for various filesystems. The ideal solution would be a user undelete command, no?

]]> By: gravisan http://www.linux-mag.com/id/7950/#comment-8871 gravisan Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7950/#comment-8871 <p>a file system that supports versioning might be a better solution then rm rm. </p> a file system that supports versioning might be a better solution then rm rm.

]]>