Interesting that you mention the multitude of file systems because
I was very surprised to see NILFS being promoted in the latest Linux
Magazine but no mention of the other more important file systems
currently in work like UnionFS ChunkFS or ext4 so publisized.
I can say I was disapointed of the
On Thu, Jul 05, 2007 at 09:57:40AM -0400, John Stoffel wrote:
> > "Erik" == Erik Mouw <[EMAIL PROTECTED]> writes:
> Erik> The only valid use of Streams in Windows I've seen was a virus
> Erik> checker that stored a hash of the file in a separate
> Erik> stream. Checking a file was a matter of r
On Wed, Jul 04, 2007 at 04:47:59PM -0400, Theodore Tso wrote:
> On Wed, Jul 04, 2007 at 07:32:34PM +0200, Erik Mouw wrote:
> > (sorry for the late reply, just got back from holiday)
> >
> > On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote:
> > > As I mentioned in my Linux.conf.au prese
On Thu, 5 Jul 2007 09:57:40 -0400
"John Stoffel" <[EMAIL PROTECTED]> wrote:
> > "Erik" == Erik Mouw <[EMAIL PROTECTED]> writes:
>
> Erik> (sorry for the late reply, just got back from holiday)
> Erik> On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote:
> >> As I mentioned in my Linu
> "Erik" == Erik Mouw <[EMAIL PROTECTED]> writes:
Erik> (sorry for the late reply, just got back from holiday)
Erik> On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote:
>> As I mentioned in my Linux.conf.au presentation a year and a half ago,
>> the main use of Streams in Windows to
On Wed, Jul 04, 2007 at 07:32:34PM +0200, Erik Mouw wrote:
> (sorry for the late reply, just got back from holiday)
>
> On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote:
> > As I mentioned in my Linux.conf.au presentation a year and a half ago,
> > the main use of Streams in Windows to
(sorry for the late reply, just got back from holiday)
On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote:
> As I mentioned in my Linux.conf.au presentation a year and a half ago,
> the main use of Streams in Windows to date has been for system
> crackers to hide trojan horse code and ro
Bryan Henderson wrote:
The directory is quite visible with a standard 'ls -a'. Instead,
they simply mark it as a separate volume/filesystem: i.e. the fsid
differs when you call stat(). The whole thing ends up acting rather like
our bind mounts.
Hmm. So it breaks user space quite a bit. By bre
Bryan Henderson wrote:
>> The directory is quite visible with a standard 'ls -a'. Instead,
>> they simply mark it as a separate volume/filesystem: i.e. the fsid
>> differs when you call stat(). The whole thing ends up acting rather like
>> our bind mounts.
>
> Hmm. So it breaks user space quite a
>The directory is quite visible with a standard 'ls -a'. Instead,
>they simply mark it as a separate volume/filesystem: i.e. the fsid
>differs when you call stat(). The whole thing ends up acting rather like
>our bind mounts.
Hmm. So it breaks user space quite a bit. By break, I mean uses that
On Tue, 2007-06-19 at 20:12 +0100, Jack Stone wrote:
> H. Peter Anvin wrote:
> > Chris Snook wrote:
> >> I pointed out NetApp's .snapshot directories because that's a method
> >> that uses legal path character, but doesn't break anything. With this
> >> method, userspace tools will have to be taug
On Mittwoch, 20. Juni 2007, H. Peter Anvin wrote:
> Alan Cox wrote:
> > POSIX is very
> > clear about what is acceptable as magic in a pathname, and the unix spec
> > even more so. The NetApp approach recognizes two important things
> >
> > 1. Old version access is the oddity not the norm
> > 2.
Trond Myklebust wrote:
>>
>> I assume NetApp flags the directory specially so that a POSIX directory
>> read doesn't get it. I've seen that done elsewhere.
>
> No. The directory is quite visible with a standard 'ls -a'. Instead,
> they simply mark it as a separate volume/filesystem: i.e. the fsi
On Jun 19, 2007, at 03:58:57, Bron Gondwana wrote:
On Mon, Jun 18, 2007 at 11:10:42PM -0400, Kyle Moffett wrote:
On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
The question remains is where to implement versioning: directly
in individual filesystems or in the vfs code so all filesystems
On Tue, 2007-06-19 at 16:35 -0700, Bryan Henderson wrote:
> >We don't need a new special character for every
> >> new feature. We've got one, and it's flexible enough to do what you
> want,
> >> as proven by NetApp's extremely successful implementation.
>
> I don't know NetApp's implementatio
>We don't need a new special character for every
>> new feature. We've got one, and it's flexible enough to do what you
want,
>> as proven by NetApp's extremely successful implementation.
I don't know NetApp's implementation, but I assume it is more than just a
choice of special character.
Jan Harkes wrote:
>
> Still, anything that depends on increasing the length of file or path
> names to refer to different versions will encounter problems for long
> file names and deep paths because there is an upper limit on file and
> path name lengths.
>
Then you have the Solaris variant --
On Tue, Jun 19, 2007 at 03:13:33PM -0700, H. Peter Anvin wrote:
> [EMAIL PROTECTED] wrote:
> >
> > the only trouble I ever had with the .snapshot approach is when tar or
> > find would decend down into the .snapshot when I didn't really intend
> > for it to do so.
> >
>
> Netapp optionally made
On Tue, Jun 19, 2007 at 03:07:40PM -0700, [EMAIL PROTECTED] wrote:
> since anything starting with . is considered a 'hidden' file per *nix
> tradition it's ignored by many programs and optionally ignored by most
> others (and anything that doesn't ignore . files when presending files to
> the us
[EMAIL PROTECTED] wrote:
>
> the only trouble I ever had with the .snapshot approach is when tar or
> find would decend down into the .snapshot when I didn't really intend
> for it to do so.
>
Netapp optionally made .snapshot not show up in readdir, which solved
that problem.
I have a bigger is
Alan Cox wrote:
>
> Yes but tdskb:foo.mac[1013,1013,frob];4 is *not* elegant.
I think describing VMS pathname syntax as "not elegant" is kind of like
describing George W. Bush as "not a genius."
> POSIX is very
> clear about what is acceptable as magic in a pathname, and the unix spec
> even mor
On Tue, 19 Jun 2007, Lennart Sorensen wrote:
On Tue, Jun 19, 2007 at 02:03:07PM -0400, Chris Snook wrote:
I pointed out NetApp's .snapshot directories because that's a method that
uses legal path character, but doesn't break anything. With this method,
userspace tools will have to be taught th
On Tue, 19 Jun 2007 12:08:52 -0700
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Chris Snook wrote:
> > I pointed out NetApp's .snapshot directories because that's a method
> > that uses legal path character, but doesn't break anything. With this
> > method, userspace tools will have to be taught
Matthew> On Tue, Jun 19, 2007 at 04:34:42PM -0400, John Stoffel wrote:
>> > "Jack" == Jack Stone <[EMAIL PROTECTED]> writes:
>>
Jack> The whole idea of the file system is that it wouldn't return the
Jack> file in the file listing. The user would have to know that the
Jack> file system was ver
On Tue, Jun 19, 2007 at 02:03:07PM -0400, Chris Snook wrote:
> I pointed out NetApp's .snapshot directories because that's a method that
> uses legal path character, but doesn't break anything. With this method,
> userspace tools will have to be taught that : is suddenly a special
> character.
On Tue, Jun 19, 2007 at 04:34:42PM -0400, John Stoffel wrote:
> > "Jack" == Jack Stone <[EMAIL PROTECTED]> writes:
>
> Jack> The whole idea of the file system is that it wouldn't return the
> Jack> file in the file listing. The user would have to know that the
> Jack> file system was versionin
John Stoffel wrote:
>> "Jack" == Jack Stone <[EMAIL PROTECTED]> writes:
>
> Jack> The whole idea of the file system is that it wouldn't return the
> Jack> file in the file listing. The user would have to know that the
> Jack> file system was versioning to access the older versions as they
> Ja
> "Jack" == Jack Stone <[EMAIL PROTECTED]> writes:
Jack> The whole idea of the file system is that it wouldn't return the
Jack> file in the file listing. The user would have to know that the
Jack> file system was versioning to access the older versions as they
Jack> would explicitly have to re
Jack Stone wrote:
Chris Snook wrote:
Jack Stone wrote:
H. Peter Anvin wrote:
Chris Snook wrote:
I pointed out NetApp's .snapshot directories because that's a method
that uses legal path character, but doesn't break anything. With this
method, userspace tools will have to be taught that : is
Chris Snook wrote:
> Okay, so now you have to modify ls, cp, tar, and thousands of other
> applications to be aware of the versioning, otherwise you can't use it.
>
> Please don't get hung up on the interface. This is a really cool
> feature that will require some serious engineering work to mak
Chris Snook wrote:
> Jack Stone wrote:
>> H. Peter Anvin wrote:
>>> Chris Snook wrote:
I pointed out NetApp's .snapshot directories because that's a method
that uses legal path character, but doesn't break anything. With this
method, userspace tools will have to be taught that : is
Jack Stone wrote:
Chris Snook wrote:
Jack Stone wrote:
The idea was that if you did an ls you would get the latest version of
the file without the :revision_num. The only visible version would be
the latest version, i.e. the current system would not change. The idea
was that it would only show
Jack Stone wrote:
H. Peter Anvin wrote:
Chris Snook wrote:
I pointed out NetApp's .snapshot directories because that's a method
that uses legal path character, but doesn't break anything. With this
method, userspace tools will have to be taught that : is suddenly a
special character.
Not to m
Chris Snook wrote:
> Jack Stone wrote:
>> The idea was that if you did an ls you would get the latest version of
>> the file without the :revision_num. The only visible version would be
>> the latest version, i.e. the current system would not change. The idea
>> was that it would only show earlier
Jack Stone wrote:
Chris Snook wrote:
But what you're talking about *will* break userspace. If I do an ls in
a directory, and get pages upon pages of versions of just one file,
that's broken. If I tar up a directory and get a tarball that's
hundreds of times larger than it should be, that's bro
H. Peter Anvin wrote:
> Jack Stone wrote:
>> But that would cause havoc with shells which use ; to seperate commands.
>> Using ; would defiantly break userspace
>>
>
> Not really. It's just a bit awkward to use, but so's the whole concept.
I think we can all agree on that after this thread but I
Jack Stone wrote:
>
> But that would cause havoc with shells which use ; to seperate commands.
> Using ; would defiantly break userspace
>
Not really. It's just a bit awkward to use, but so's the whole concept.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
H. Peter Anvin wrote:
> Chris Snook wrote:
>> I pointed out NetApp's .snapshot directories because that's a method
>> that uses legal path character, but doesn't break anything. With this
>> method, userspace tools will have to be taught that : is suddenly a
>> special character.
>
> Not to menti
Chris Snook wrote:
> I pointed out NetApp's .snapshot directories because that's a method
> that uses legal path character, but doesn't break anything. With this
> method, userspace tools will have to be taught that : is suddenly a
> special character.
Not to mention that the character historical
Chris Snook wrote:
> But what you're talking about *will* break userspace. If I do an ls in
> a directory, and get pages upon pages of versions of just one file,
> that's broken. If I tar up a directory and get a tarball that's
> hundreds of times larger than it should be, that's broken. If you
Jack Stone wrote:
Chris Snook wrote:
The underlying internal implementation of something like this wouldn't
be all that hard on many filesystems, but it's the interface that's the
problem. The ':' character is a perfectly legal filename character, so
doing it that way would break things.
But
Kyle Moffett wrote:
> On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
>>> The question remains is where to implement versioning: directly in
>>> individual filesystems or in the vfs code so all filesystems can
>>> use it?
>>
>> Or not in the kernel at all. I've been doing versioning of t
Jeremy Allison wrote:
>
> I'm not talking WinFS, I'm talking streams. Streams are already
> being used (mainly by malware writers of course - but hey, don't
> you want full compatibility ? :-).
>
Reminds me of the Linux Journal (I believe?) article which did
viruses-on-Wine compatibility tes
On Tue, Jun 19, 2007 at 03:05:07AM -0400, Theodore Tso wrote:
>
> There is a partial implementation lieing around somewhere, but there
> were a number of problems we ran into that were discussed in the
> slidedeck. Basically, if the only program accessing the files
> containing forks was the Samb
On 6/19/07, Kyle Moffett <[EMAIL PROTECTED]> wrote:
What I think would be particularly interesting in this domain is
something similar in concept to GIT, except in a file-system:
perhaps stating the blindingly obvious, but there was an early
implementation of a FUSE-based gitfs --
http://www.sf
On Mon, Jun 18, 2007 at 11:10:42PM -0400, Kyle Moffett wrote:
> On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
>>> The question remains is where to implement versioning: directly in
>>> individual filesystems or in the vfs code so all filesystems can use it?
>>
>> Or not in the kernel at all
Kyle Moffett wrote:
> On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
>>> The question remains is where to implement versioning: directly in
>>> individual filesystems or in the vfs code so all filesystems can use it?
>>
>> Or not in the kernel at all. I've been doing versioning of the types
On Mon, Jun 18, 2007 at 03:48:15PM -0700, Jeremy Allison wrote:
> Did you ever code up forkdepot ? Just wondering ?
There is a partial implementation lieing around somewhere, but there
were a number of problems we ran into that were discussed in the
slidedeck. Basically, if the only program acces
On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote:
> The main difference appears to be the potential size. Both extended
> attributes and forks allow for extra data that I neither want or need.
> But once the extra space is large enough to hide a rootkit in, it
> becomes a security proble
On Jun 18, 2007, at 17:24:23, Brad Boyer wrote:
On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote:
Pointless here means that _I_ don't see the point. Maybe there
are valid uses for extended attributes. If there are, noone has
explained them to me yet.
The users of extended attrib
On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
The question remains is where to implement versioning: directly in
individual filesystems or in the vfs code so all filesystems can
use it?
Or not in the kernel at all. I've been doing versioning of the
types I described for years with
On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote:
> Pointless here means that _I_ don't see the point. Maybe there are
> valid uses for extended attributes. If there are, noone has explained
> them to me yet.
The users of extended attributes that I've dealt with are ACL support
and SEL
On Mon, Jun 18, 2007 at 11:32:38AM -0400, Chris Mason wrote:
> On Mon, Jun 18, 2007 at 03:45:24AM -0600, Andreas Dilger wrote:
> > Too bad everyone is spending time on 10 similar-but-slightly-different
> > filesystems. This will likely end up with a bunch of filesystems that
> > implement some eas
On Mon, 18 Jun 2007, Jeremy Allison wrote:
Just because I now agree with you that streams are
a bad idea doesn't mean the pressure to support them
in some way in Samba has gone away :-).
Having dealt with Stream's support[1] in the past, I can assure you it is
a bad idea. ]:>
[1] http://ww
On Tue, 19 Jun 2007, Jörn Engel wrote:
On Mon, 18 June 2007 18:10:21 -0400, Theodore Tso wrote:
On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote:
And that makes them different from extended attributes, how?
Both of these really are nothing but ad hocky syntactic sugar for
direct
On Mon, Jun 18, 2007 at 06:10:21PM -0400, Theodore Tso wrote:
> On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote:
> > And that makes them different from extended attributes, how?
> >
> > Both of these really are nothing but ad hocky syntactic sugar for
> > directories, sometimes comb
On Mon, 18 Jun 2007, H. Peter Anvin wrote:
alan wrote:
On Mon, 18 Jun 2007, Bodo Eggert wrote:
alan <[EMAIL PROTECTED]> wrote:
I just wish that people would learn from the mistakes of others. The
MacOS is a prime example of why you do not want to use a forked
filesystem, yet some people st
On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote:
>
> Pointless here means that _I_ don't see the point. Maybe there are
> valid uses for extended attributes. If there are, noone has explained
> them to me yet.
Samba uses them to store DOS'ism's that you don't want in your
POSIX files
On Mon, 18 June 2007 18:10:21 -0400, Theodore Tso wrote:
> On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote:
> > And that makes them different from extended attributes, how?
> >
> > Both of these really are nothing but ad hocky syntactic sugar for
> > directories, sometimes combined
On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote:
> And that makes them different from extended attributes, how?
>
> Both of these really are nothing but ad hocky syntactic sugar for
> directories, sometimes combined with in-filesystem support for small
> data items.
There's a good
On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote:
> And that makes them different from extended attributes, how?
Streams on systems that support them allow lseek and are
accessed by fd's. EA's are always a blob of data, read/written
in their entirity.
Jeremy.
-
To unsubscribe from
alan wrote:
> On Mon, 18 Jun 2007, Bodo Eggert wrote:
>
>> alan <[EMAIL PROTECTED]> wrote:
>>
>>> I just wish that people would learn from the mistakes of others. The
>>> MacOS is a prime example of why you do not want to use a forked
>>> filesystem, yet some people still seem to think it is a go
On Mon, 18 Jun 2007, Bodo Eggert wrote:
alan <[EMAIL PROTECTED]> wrote:
I just wish that people would learn from the mistakes of others. The
MacOS is a prime example of why you do not want to use a forked
filesystem, yet some people still seem to think it is a good idea.
(Forked filesystems t
alan <[EMAIL PROTECTED]> wrote:
> I just wish that people would learn from the mistakes of others. The
> MacOS is a prime example of why you do not want to use a forked
> filesystem, yet some people still seem to think it is a good idea.
> (Forked filesystems tend to be fragile and do not play we
On Mon, Jun 18, 2007 at 04:30:33PM -0400, Theodore Tso wrote:
> Well, I just want to make sure people know that Samba isn't asking for
> it any more, and I don't know of any current requests outstanding from
> any of the userspace projects. So there's no one we need to ship off
> to the re-educati
On Mon, Jun 18, 2007 at 10:33:42AM -0700, Jeremy Allison wrote:
>
> Yeah, ok - but do you have to rub my nose in it every chance you get ?
>
> :-) :-).
Well, I just want to make sure people know that Samba isn't asking for
it any more, and I don't know of any current requests outstanding from
an
>The question remains is where to implement versioning: directly in
>individual filesystems or in the vfs code so all filesystems can use it?
Or not in the kernel at all. I've been doing versioning of the types I
described for years with user space code and I don't remember feeling that
I compr
On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote:
> On Mon, Jun 18, 2007 at 09:16:30AM -0700, alan wrote:
> >
> > I just wish that people would learn from the mistakes of others. The
> > MacOS is a prime example of why you do not want to use a forked
> > filesystem, yet some people
Theodore Tso wrote:
>
> As I mentioned in my Linux.conf.au presentation a year and a half ago,
> the main use of Streams in Windows to date has been for system
> crackers to hide trojan horse code and rootkits so that system
> administrators couldn't find them. :-)
>
But... that's an essential
On Mon, Jun 18, 2007 at 09:16:30AM -0700, alan wrote:
>
> I just wish that people would learn from the mistakes of others. The
> MacOS is a prime example of why you do not want to use a forked
> filesystem, yet some people still seem to think it is a good idea.
> (Forked filesystems tend to be
Jack Stone wrote:
>>
>> Later, I discovered what I think are superior alternatives: RCS-style
>> version management on top of the filesystem, and automatic versioning
>> based on time instead of count of "modifications." For example, make a
>> copy of every changed file every hour and keep it
Bryan Henderson wrote:
>> Part of the problem is that "whenever you modify a file"
>> is ill-defined, or rather, if you were to take the literal meaning of it
>> you'd end up with an unmanageable number of revisions.
>
> Let me expand on that. Do you want to save a revision every time the user
>
On Mon, 18 Jun 2007, Theodore Tso wrote:
On Mon, Jun 18, 2007 at 03:45:24AM -0600, Andreas Dilger wrote:
Too bad everyone is spending time on 10 similar-but-slightly-different
filesystems. This will likely end up with a bunch of filesystems that
implement some easy subset of features, but will
On Mon, Jun 18, 2007 at 03:45:24AM -0600, Andreas Dilger wrote:
> Too bad everyone is spending time on 10 similar-but-slightly-different
> filesystems. This will likely end up with a bunch of filesystems that
> implement some easy subset of features, but will not get polished for
> users or have a
On Mon, Jun 18, 2007 at 03:45:24AM -0600, Andreas Dilger wrote:
> Too bad everyone is spending time on 10 similar-but-slightly-different
> filesystems. This will likely end up with a bunch of filesystems that
> implement some easy subset of features, but will not get polished for
> users or have a
On Mon, 18 June 2007 03:45:24 -0600, Andreas Dilger wrote:
>
> Too bad everyone is spending time on 10 similar-but-slightly-different
> filesystems. This will likely end up with a bunch of filesystems that
> implement some easy subset of features, but will not get polished for
> users or have a f
Andreas Dilger wrote:
> Too bad everyone is spending time on 10 similar-but-slightly-different
> filesystems. This will likely end up with a bunch of filesystems that
> implement some easy subset of features, but will not get polished for
> users or have a full set of features implemented (e.g. AC
On Jun 16, 2007 16:53 +0200, Jörn Engel wrote:
> On Fri, 15 June 2007 15:51:07 -0700, alan wrote:
> > >Thus, in the end it turns out that this stuff is better handled by
> > >explicit version-control systems (which require explicit operations to
> > >manage revisions) and atomic snapshots (for bac
On Sat, Jun 16, 2007 at 11:17:58PM +0100, Alan Cox wrote:
> > (Vax/VMS System Software Handbook)
> > (TOPS-20 User's Manual)
>
> Also Files/11
And don't forget the really ground breaking work (for the
time) done by the Xanadu folk.
-
To unsubscribe from this list: send the line "unsubscribe
Jeffrey V. Merkey wrote:
The trick in the NetWare 3 model was to segregate the directory
entries onto special reserved
4K directory blocks (128 byte dir records). When it came time to purge
storage after the file system filled, an entire 4K block and all
chains was deleted during block allocati
Alan Cox wrote:
(Vax/VMS System Software Handbook)
(TOPS-20 User's Manual)
Also Files/11
Basic versioning goes back to at least ITS
Not sure how old doing file versioning and hiding it away with a tool to
go rescue the stuff you blew away by mistake is, but Novell Netware 3
certainly
> (Vax/VMS System Software Handbook)
> (TOPS-20 User's Manual)
Also Files/11
Basic versioning goes back to at least ITS
Not sure how old doing file versioning and hiding it away with a tool to
go rescue the stuff you blew away by mistake is, but Novell Netware 3
certainly did a good job on t
DEC had versioning files systems 30 years ago. Any
patents on their style must certainly have expired
long ago.
Look at RSX-11 and other seventies era operating
systems.
This is ancient stuff.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Jan Harkes wrote:
> Sites like portal.acm.org and citeseer.ist.psu.edu are good places to
> find copies of these papers. They also provide links to other work that
> either is cited by, or cites these papers which is a convenient way to
> find other papers in this area.
>
> Researching, designing
On Sat, Jun 16, 2007 at 02:03:49PM -0600, Jeffrey V. Merkey wrote:
> Jan Harkes wrote:
> >implementation, just a high level description. Finally advising anyone
> >(who is not an actual patent lawyer that could correctly interpret the
> >language and scope of a patent) to go search out patents seem
Alan Cox wrote:
http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENG&DBSELECT=PCT&SERVER_TYPE=19&SORT=1211506-KEY&TYPE_FIELD=256&IDB=0&IDOC=1205953&C=10&ELEMENT_SET=IA,WO,TTL-EN&RESULT=1&TOTAL=3&START=1&DISP=25&FORM=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENG&SEARCH_IA=US2005045566&QUERY=%28IN%2fmerkey%29+
> http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENG&DBSELECT=PCT&SERVER_TYPE=19&SORT=1211506-KEY&TYPE_FIELD=256&IDB=0&IDOC=1205953&C=10&ELEMENT_SET=IA,WO,TTL-EN&RESULT=1&TOTAL=3&START=1&DISP=25&FORM=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENG&SEARCH_IA=US2005045566&QUERY=%28IN%2fmerkey%29+
>
> The last on
Jeffrey V. Merkey wrote:
> When you get into the recycling issues with storage, the patents come
> into play. Also, using the file name to reference revisions is already
> the subject of a patent previously filed (I no longer own the patent, I
> sold them to Canopy). There is a third one about to b
Jan Harkes wrote:
On Sat, Jun 16, 2007 at 04:12:14AM -0600, Jeffrey V. Merkey wrote:
Jeffrey V. Merkey wrote:
over). There's also another patent filed as well. It's a noble
effort to do a free version, but be aware there's some big guns with
patents out there already, not to mention
Mark Williamson wrote:
I reviewed your sample implementation, and it appears to infringe 3
patents already.You should do some research on this.
Are you able to tell us which areas of the code infringe existing patents?
Yes.
Jeff
Cheers,
Mark
-
To unsubscribe from t
On Sat, Jun 16, 2007 at 04:12:14AM -0600, Jeffrey V. Merkey wrote:
> Jeffrey V. Merkey wrote:
> >over). There's also another patent filed as well. It's a noble
> >effort to do a free version, but be aware there's some big guns with
> >patents out there already, not to mention doing this is comp
On Fri, 15 June 2007 15:51:07 -0700, alan wrote:
>
> >Thus, in the end it turns out that this stuff is better handled by
> >explicit version-control systems (which require explicit operations to
> >manage revisions) and atomic snapshots (for backup.)
>
> ZFS is the cool new thing in that space.
> I reviewed your sample implementation, and it appears to infringe 3
> patents already.You should do some research on this.
Are you able to tell us which areas of the code infringe existing patents?
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no pe
"Jeffrey V. Merkey" <[EMAIL PROTECTED]> writes:
> This already exists -- it just not open sourced, and you could spend
> years trying to create it. Trust me, once you start dealing with the
> distributed issues with this, its gets very complex. I am not meaning
> to discourage you, but there are
Hi,
On Fri, Jun 15, 2007 at 04:01:14PM -0700, alan wrote:
> On Fri, 15 Jun 2007, Kok, Auke wrote:
> >
> >
> >have you looked into ext3cow? it allows you to take snapshots of the
> >entire ext3 fs at a single point, and rollback / extract snapshots at any
> >time later. This may be sufficient for
Jeffrey V. Merkey wrote:
This already exists -- it just not open sourced, and you could spend
years trying to create it. Trust me, once you start dealing with the
distributed issues with this, its gets very complex. I am not meaning
to discourage you, but there are patents already filed on
This already exists -- it just not open sourced, and you could spend
years trying to create it. Trust me, once you start dealing with the
distributed issues with this, its gets very complex. I am not meaning
to discourage you, but there are patents already filed on this on
Linux.So you
Chris Snook wrote:
> The underlying internal implementation of something like this wouldn't
> be all that hard on many filesystems, but it's the interface that's the
> problem. The ':' character is a perfectly legal filename character, so
> doing it that way would break things.
But to work withou
alan wrote:
> On Fri, 15 Jun 2007, H. Peter Anvin wrote:
>> This is one of those things that seems like a good idea, but frequently
>> ends up short. Part of the problem is that "whenever you modify a file"
>> is ill-defined, or rather, if you were to take the literal meaning of it
>> you'd end up
On Fri, 15 Jun 2007, H. Peter Anvin wrote:
alan wrote:
ZFS is the cool new thing in that space. Too bad the license makes it
hard to incorporate it into the kernel. (I am one of those people that
believe that Linux should support EVERY file system, no matter how old
or obscure.)
I have de
1 - 100 of 106 matches
Mail list logo
