From: Mark Richards <richard@ecf.utoronto.ca>
To: Helge Hafting <helgehaf@idb.hist.no>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Multiplexing filesystem
Date: Wed, 28 Nov 2001 20:56:05 -0500 [thread overview]
Message-ID: <3C0595B5.5B769949@ecf.utoronto.ca> (raw)
In-Reply-To: <3C030FB4.C3303BE4@ecf.utoronto.ca> <3C036A83.F23E6EBE@idb.hist.no> <3C03A702.EBE823C9@ecf.utoronto.ca> <3C04C65D.5614D04A@idb.hist.no>
Helge Hafting wrote:
> Mark Richards wrote:
> [...]
> > I'll look into Coda, but ideally I wouldn't have to copy each file to the local
> > workstation when I use it, only when it is reserved for editing. Also, I'd like to
> > be able to store the local copy anywhere on the filesystem, if possible.
>
> Worried your drive will fill up? The files copied to your
> drive is merely copied as a "caching" operation. They
> still seem to reside at the server - this is totally transparent.
> And of course you can limit this caching - if too many files
> is cached some is simply thrown away. (Or sent back
> if they were changed.) They will be re-
> loaded automatically if you ever need them again.
>
> If you really want to store them where you want instead of
> transparent access, why bother with a new FS at all?
> (I believe coda lets you specify where the caching
> will happen, if you have several partitions/drives)
>
> Simply run a script that reserves the file (by using
> the permission system) and *copy* it to
> where you want. Check-in will consist of copying
> the altered file back, and restore normal permissions.
>
> You might even want to run a system like CVS, unless
> there is some special reason for not doing that.
Heh, it's funny that you mention that, because one of the goals of this project is to
access a CVS-like repository as if it were a filesystem. I suppose that i'm not opposed
to on-disk caching of files; this may improve performance in some cases. However, the
specific feature I need right now is that a file being modified by one person is
explicitly not seen by other people (they see the original version). The parts that
need to be transparent to the user are the copying/moving of the file from one place
(network) to another (somewhere else). Also, files created locally should not be
propagated back to the network unless the users explicitly specifies that they should.
So, this system is not totally transparent to the user (because we can't read the user's
mind to figure out what files (s)he would like to edit or 'check in'), but the
filesystem part of it should be. Plus, it's important that local files and network
files appear in the same directory side by side, as if they were in the same directory
on the server.
I still haven't had a chance to look at Coda; maybe it does solve my problem, but
probably not quite.
Mark
>
>
> Helge Hafting
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2001-11-29 1:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-27 3:59 Multiplexing filesystem Mark Richards
2001-11-27 4:34 ` Jeff V. Merkey
2001-11-27 4:39 ` Jeff V. Merkey
2001-11-27 7:38 ` James Davies
2001-11-28 0:34 ` Pavel Machek
2001-11-27 10:27 ` Helge Hafting
2001-11-27 14:45 ` Mark Richards
2001-11-27 19:37 ` Mike Fedyk
2001-11-28 11:11 ` Helge Hafting
2001-11-29 1:56 ` Mark Richards [this message]
2001-11-27 15:15 ` Eli Carter
2001-11-27 23:39 ` Blake Barnett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C0595B5.5B769949@ecf.utoronto.ca \
--to=richard@ecf.utoronto.ca \
--cc=helgehaf@idb.hist.no \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox