Nathan Kroenert wrote:
Anyhoo - What do you think the chances are that any application vendor
is going to write in special handling for Solaris file removal? I'm
guessing slim to none, but have been wrong before...
Agreed. However, to this I reply: Who Cares? I'm guessing that 99% of
the po
On Wed, 2006-05-31 at 03:48, Erik Trimble wrote:
> (I'm going to combine Constantine & Eric's replies together, so I
> apologize for the possible confusion):
>
Apology accepted. :)
Anyhoo - What do you think the chances are that any application vendor
is going to write in special handling for S
(I'm going to combine Constantine & Eric's replies together, so I
apologize for the possible confusion):
On Tue, 2006-05-30 at 16:50 +0200, Constantin Gonzalez Schmitz wrote:
> Hi,
>
> so we have two questions:
>
> 1. Is it really ZFS' job to provide an undo functionality?
>
> 2. If it turns o
On Tue, 2006-05-30 at 09:48 -0700, Eric Schrock wrote:
> - doesn't work over NFS/CIFS (recycle bin 'location' may not be
> accessible on all hosts, or may require cross-network traffic to
> delete a file).
> - inherently user-centric, not filesystem-centric (location of stored
> file depends
On Mon, May 29, 2006 at 11:00:29PM -0700, Erik Trimble wrote:
> Once again, I hate to be a harpy on this one, but are we really
> convinced that having a "undo" (I'm going to call is RecycleBin from now
> on) function for file deletion built into ZFS is a good thing?
>
> Since I've seen nothing
hey All,
On Tue, 2006-05-30 at 16:50 +0200, Constantin Gonzalez Schmitz wrote:
> - The purpose of any Undo-like action is to provide a safety net to the user
>in case she commits an error that she wants to undo.
So, what if the user was able to specify which applications they wanted
such a sa
Hi,
so we have two questions:
1. Is it really ZFS' job to provide an undo functionality?
2. If it turns out to be a feature that needs to be implemented by
ZFS, what is the better approach: Snapshot based or file-based?
My personal opinion on 1) is:
- The purpose of any Undo-like action is
Once again, I hate to be a harpy on this one, but are we really
convinced that having a "undo" (I'm going to call is RecycleBin from now
on) function for file deletion built into ZFS is a good thing?
Since I've seen nothing to the contrary, I'm assuming that we're doing
this by changing the ac
Constantin Gonzalez wrote On 05/29/06 02:50,:
Hi,
the current discussion on how to implement "undo" seems to circulate around
concepts and tweaks for replacing any "rm" like action with "mv" and then
fix the problems associated with namespaces, ACLs etc.
Why not use snapshots?
A snapshot-ori
Hello Constantin,
On 5/29/06, Constantin Gonzalez <[EMAIL PROTECTED]> wrote:
Hi,
the current discussion on how to implement "undo" seems to circulate around
concepts and tweaks for replacing any "rm" like action with "mv" and then
fix the problems associated with namespaces, ACLs etc.
Why not
Hi,
the current discussion on how to implement "undo" seems to circulate around
concepts and tweaks for replacing any "rm" like action with "mv" and then
fix the problems associated with namespaces, ACLs etc.
Why not use snapshots?
A snapshot-oriented implementation of undo would:
- Create a s
Joerg Schilling wrote:
"Jeremy Teo" <[EMAIL PROTECTED]> wrote:
Hello,
with reference to bug id #4852821: user undo
I have implemented a basic prototype that has the current functionality:
1) deleted files/directories are moved to /your_pool/your_fs/.zfs/deleted
Unfortunately, it is non-triv
"Jeremy Teo" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> with reference to bug id #4852821: user undo
>
> I have implemented a basic prototype that has the current functionality:
>
> 1) deleted files/directories are moved to /your_pool/your_fs/.zfs/deleted
> Unfortunately, it is non-trivial to complet
On Wed, May 24, 2006 at 07:10:52PM -0500, Mike Gerdts wrote:
> If it were unlink(3C) rather than unlink(2), an interposer library
> could make this functionality generally available. Surely there must
> be a dtrace hack that could redirect calls destined for unlink() to
> safe_unlink(), subject to
On 5/24/06, Erik Trimble <[EMAIL PROTECTED]> wrote:
So, our mythical system library (libundelete.so) should support a couple
of generic functions (say: int safe_unlink(const char *path), and void
empty_recyclebin(const char *path) which look for an ENV variable to
determine if they should recycl
Cool -
I can see my old fav's from Netware 3.12 making a comeback.
It was always great to be able to salvage things from a disk that
someone did not mean to kill. :)
ah - salvage - my old friend...
Does this also usher in the return of purge too? :)
Nathan.
Erik Trimble wrote:
On Wed, 2
On Wed, 2006-05-24 at 14:43 -0700, Eric Schrock wrote:
> No, this is not the point of this RFE. We are not trying to implement a
> wide-ranging subsystem that understands how to manage semantically valid
> undo points. This would never, ever, be supported by any significant
> number of applicatio
On Wed, May 24, 2006 at 02:43:38PM -0700, Eric Schrock wrote:
> No, this is not the point of this RFE. We are not trying to implement a
> wide-ranging subsystem that understands how to manage semantically valid
> undo points. This would never, ever, be supported by any significant
> number of app
On Wed, May 24, 2006 at 12:18:48PM -0700, Erik Trimble wrote:
>
> But my point being that "undo" is appropriate at the APPLICATION level,
> not the FILESYSTEM level. An application (whether Nautilus or "rm")
> should have the ability to call a system library to support "undo",
> which has the rel
On Wed, 2006-05-24 at 11:31 -0700, Eric Schrock wrote:
> On Wed, May 24, 2006 at 11:22:23AM -0700, Erik Trimble wrote
> > Isn't this an application feature, not a filesystem feature? I would
> > expect something like this behavior when using Nautilus, but certainly
> > not when using "rm".
>
> Th
On Wed, May 24, 2006 at 11:22:23AM -0700, Erik Trimble wrote:
> U.
>
> Remind me why we should support "undo" (or, more aptly named, "safe
> delete") in ZFS?
>
> Isn't this an application feature, not a filesystem feature? I would
> expect something like this behavior when using Nautilus, bu
U.
Remind me why we should support "undo" (or, more aptly named, "safe
delete") in ZFS?
Isn't this an application feature, not a filesystem feature? I would
expect something like this behavior when using Nautilus, but certainly
not when using "rm".
That is, maybe there should be a library w
Other possibilities:
- put a .deleted directory in every directory (not on by default, for
POSIX compliance)
- put a link in .deleted named after the file's dnode and append a text
({fname, dnode#}) entry to a log file so it can more easily be found
Ultimately deleted files' space has to
On Wed, 2006-05-24 at 12:22, James Dickens wrote:
> how about changing the name of the file to uid or username-filename
> this atleast gets you the ability to let each user the ability to
> delete there own file, shouldn't be much work. Another possible
> enhancement would be adding anything field
On 5/24/06, Jeremy Teo <[EMAIL PROTECTED]> wrote:
Hello,
with reference to bug id #4852821: user undo
I have implemented a basic prototype that has the current functionality:
1) deleted files/directories are moved to /your_pool/your_fs/.zfs/deleted
Unfortunately, it is non-trivial to completel
Jeremy Teo wrote:
Hello,
with reference to bug id #4852821: user undo
I have implemented a basic prototype that has the current functionality:
1) deleted files/directories are moved to /your_pool/your_fs/.zfs/deleted
Unfortunately, it is non-trivial to completely reproduce the namespace
of del
26 matches
Mail list logo
