On Fri, 29 Oct 2010, Bruce Cran wrote:
On Thu, 28 Oct 2010 14:11:14 -0700 Garrett Cooper
wrote:
Unfortunately it's implied superficially by the 3 pass tort; but as most
people who understand magnetic disks know, unless you completely obliterate
a disk, wipe over it with random data enough t
On Thu, 28 Oct 2010 14:11:14 -0700
Garrett Cooper wrote:
> Unfortunately it's implied superficially by the 3 pass tort; but as
> most people who understand magnetic disks know, unless you completely
> obliterate a disk, wipe over it with random data enough times,
> whatever, the content is still
Quoting Garrett Cooper (from Thu, 28 Oct 2010
14:11:14 -0700):
Unfortunately it's implied superficially by the 3 pass tort; but as
most people who understand magnetic disks know, unless you completely
obliterate a disk, wipe over it with random data enough times,
whatever, the content is stil
On Thu, 28 Oct 2010, Alexander Best wrote:
For example, you could imagine a pathconf() call that asks the file system
if overwriting a file is likely to result in the data going away -- UFS
could answer "yes" unless it's snapshotting the file system, and ZFS could
simply answer "no".
In Fre
On Thu Oct 28 10, Robert Watson wrote:
> On Thu, 28 Oct 2010, Gary Jennejohn wrote:
>
> >>>The -P option assumes that the underlying storage overwrites file block
> >>>when data is written on existing offset. Several factors including the
> >>>file system and its backing store could defeat the
On Thu, 28 Oct 2010, Gary Jennejohn wrote:
The -P option assumes that the underlying storage overwrites file block
when data is written on existing offset. Several factors including the
file system and its backing store could defeat the assumption, this
includes, but is not limited to file sy
On Thu Oct 28 10, Ceri Davies wrote:
> On Thu, Oct 28, 2010 at 10:25:47AM +, Alexander Best wrote:
> > On Thu Oct 28 10, Gary Jennejohn wrote:
> > > On Thu, 28 Oct 2010 16:22:05 +1100 (EST)
> > > Bruce Evans wrote:
> > >
> > > > On Wed, 27 Oct 2010, Xin LI wrote:
> > > >
> > > > > I think wh
On Thu, Oct 28, 2010 at 10:25:47AM +, Alexander Best wrote:
> On Thu Oct 28 10, Gary Jennejohn wrote:
> > On Thu, 28 Oct 2010 16:22:05 +1100 (EST)
> > Bruce Evans wrote:
> >
> > > On Wed, 27 Oct 2010, Xin LI wrote:
> > >
> > > > I think what really defeats -P is the fact that the file system
On Thu Oct 28 10, Gary Jennejohn wrote:
> On Thu, 28 Oct 2010 16:22:05 +1100 (EST)
> Bruce Evans wrote:
>
> > On Wed, 27 Oct 2010, Xin LI wrote:
> >
> > > I think what really defeats -P is the fact that the file system or
> > > underlying data storage would not overwrite data on a file at sync()
On Thu, Oct 28, 2010 at 09:55:38AM +0200, Gary Jennejohn wrote:
> On Thu, 28 Oct 2010 16:22:05 +1100 (EST)
> Bruce Evans wrote:
>
> > On Wed, 27 Oct 2010, Xin LI wrote:
> >
> > > I think what really defeats -P is the fact that the file system or
> > > underlying data storage would not overwrite
On Thu, 28 Oct 2010 16:22:05 +1100 (EST)
Bruce Evans wrote:
> On Wed, 27 Oct 2010, Xin LI wrote:
>
> > I think what really defeats -P is the fact that the file system or
> > underlying data storage would not overwrite data on a file at sync().
> > COW is of course one of the case, journaling MAY
On Wed, 27 Oct 2010, Xin LI wrote:
I think what really defeats -P is the fact that the file system or
underlying data storage would not overwrite data on a file at sync().
COW is of course one of the case, journaling MAY defeat -P but is not
guaranteed. FS with variable block size - I believe t
On Wed, Oct 27, 2010 at 03:33:01PM -0700, Xin LI wrote:
> Maybe something like:
>
> BUGS
>
> The -P option assumes that the underlying storage overwrites file block
> when data is written on existing offset. Several factors including the
> file system and its backing store could defeat the assum
On Wed Oct 27 10, Xin LI wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 10/27/10 14:48, Alexander Best wrote:
> > On Wed Oct 27 10, Doug Barton wrote:
> >> On 10/27/10 14:26, Alexander Best wrote:
> >>> are in fact COW fs the only exception where the -P flag won't work? before
>
On Wed Oct 27 10, Juli Mallett wrote:
> On Wed, Oct 27, 2010 at 14:48, Alexander Best wrote:
> > On Wed Oct 27 10, Doug Barton wrote:
> >> What may be a better approach is to confirm the fs' that DO work, list
> >> them, and then add something to the effect of, "This feature is unlikely
> >> to wo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/27/10 14:48, Alexander Best wrote:
> On Wed Oct 27 10, Doug Barton wrote:
>> On 10/27/10 14:26, Alexander Best wrote:
>>> are in fact COW fs the only exception where the -P flag won't work? before
>>> r213582 LFS was mentioned here and that the
On Wed, Oct 27, 2010 at 14:48, Alexander Best wrote:
> On Wed Oct 27 10, Doug Barton wrote:
>> What may be a better approach is to confirm the fs' that DO work, list
>> them, and then add something to the effect of, "This feature is unlikely
>> to work on other file systems."
>
> i don't think tha
On Wed Oct 27 10, Doug Barton wrote:
> On 10/27/10 14:26, Alexander Best wrote:
> >are in fact COW fs the only exception where the -P flag won't work? before
> >r213582 LFS was mentioned here and that the block size must be fixed.
> >also the comment in rm.c says that -P won't work for any logging
On 10/27/10 14:26, Alexander Best wrote:
are in fact COW fs the only exception where the -P flag won't work? before
r213582 LFS was mentioned here and that the block size must be fixed.
also the comment in rm.c says that -P won't work for any logging file systems.
i'm not a fs expert, but i think
On Wed Oct 27 10, Dag-Erling Smorgrav wrote:
> Author: des
> Date: Wed Oct 27 18:48:23 2010
> New Revision: 214431
> URL: http://svn.freebsd.org/changeset/base/214431
>
> Log:
> Language cleanup.
>
> Modified:
> head/bin/rm/rm.1
>
> Modified: head/bin/rm/rm.1
> ==
Author: des
Date: Wed Oct 27 18:48:23 2010
New Revision: 214431
URL: http://svn.freebsd.org/changeset/base/214431
Log:
Language cleanup.
Modified:
head/bin/rm/rm.1
Modified: head/bin/rm/rm.1
==
--- head/bin/rm/rm.1
21 matches
Mail list logo
