Chad Leigh -- Shire.Net LLC wrote:
But see, that assumes you have a logout-type functionality to use.
Which indeed is possible for command-line usage, but then only in a
very limited way. During a typical session, I access almost 20
NFS-mounted directories. And anyone using autofs/automount trees gets
even more. You're saying that my logout script has to know about all
of them to keep things clean? That's unrealistic.
It is up to you to come up with a scheme to keep things clean, the
same way you do now anyway (downloads, etc),
Which is entirely reasonable if the number of places where FV is
limited, but completely unrealistic if FV is turned on for a large
number of places. And much more difficult for those restricted to
accessing File Versioned directories over a netFS, where scripting
cleanups can be difficult or highly impractical.
And that still doesn't solve the problem of people who use SAMBA or
NFS from machines which don't have an interactive shell logout system
(i.e. Windows).
It is still mounted on their desktops and they can still delete files
with FV the same way they do now
No real issue.
Well.... If the versions of everything are kept in the same directory,
then you are going to have a VERY bad user experience with people using
GUI file browsers. Cleaning up multiple versions of the same file name
is going to be tricky, and you will find people very frequently
accidentally delete the wrong thing. More importantly, people are going
to consider it a big hassle to have to keep things tidy by hand. If
the versioning is kept somewhere different than the "current" file
version, then this mitigates things a bit, but you still don't want to
require people to clean this stuff up via a GUI. And, with Windows,
asking users to use the command prompt for what is normally a GUI
operation isn't acceptable, from a general usability standpoint.
This worked fine for the users I knew; even on a system that didn't
The problem is we are comparing apples to oranges in user bases here.
TOPS-20 systems had a couple of dozen users (or, at most, a few
hundred). VMS only slightly more. UNIX/POSIX systems have 10s of
thousands.
Rarely. Most of them have in the same range as VMS now or then.
Very, Very few VMS systems that I know about had more than a couple
hundred users. MIT's main VMS server had only about 2000, with less
than half that active. A couple of Fortune 500 companies I've worked at
in the 90s had VMS systems, and they had very restricted user bases.
VMS simply was never used as a general-purpose file server, and if there
were a fairly large number of users, they were logged in via some custom
app, and never really used the system in the manner we are discussing here.
On the other hand, virtually all the companies I've worked for have had
a UNIX-based file server, with at least a hundred or more UIDs. And
with Single Sign-on and LDAP becoming the way to go, even mid-sized
companies have systems with over a 1000 users. 10,000 active users
isn't hard to come up with at all. And, given that Enterprises are a
main target for ZFS, millions of users are entirely within reason.
But this requires modifying all the relevant apps, which is the same
amount of work as modifying them to use a new FV API. It's not
transparent to the end-user.
Because the semantics of a file name are different on a unix/posix
system than they are on a VMS or TOPS-20 system, which had more
structured filenames. I would say that the version cannot be an
actual part of the file name but would have to be meta data. However,
it could display as part of the username and the underlying system can
be made to do the right thing
ie,
"foo" gets you the latest "foo"
Specifically entering in foo;7 gets you version 7 or the latest if
there are less than 7 versions available. The app can think of it as
being part of the file name, but the underlying system would have to
know how to do the right thing in extracting the version out and
making it meta data. Takes some thinking and I am not claiming to
have all the answers right now, but hardly undoable.
No app changes are necessary.
No, this is untrue. Remember that you can't use any character to
indicate FV, as all characters are valid POSIX file names. (well, except
'/'). You CAN'T say "foo;8" gives me version 8 of the file "foo",
because there very well might be a completely different file name
"foo;8" that is NOT any version of the file foo. VMS and TOPS had
reserved characters for file versioning, and thus you were set. This
isn't true in UNIX filesystems.
The only way to do FV in the POSIX concept is to either keep the file
versions in a separate file tree than the "current" files, or to use
some sort of an API to access them, and otherwise keep them normally
hidden from view.
You can't dodge this by simply saying "oh, well, then change the FV
delimiter if it causes you problems". Aside from the fact that you are
breaking POSIX compatibility by reserving some character for special
use, how confusing would it be to users if the FV delimiter is ";" in
this directory, "&" in that directory, "_" in the one over there, etc.
? That's entirely possible, given the demands of many Windows apps for
file naming.
-Erik
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
