Subject: Ftp-WG: MLST-07

From: Dave Cridland <[email-masked]>
Date: Mon, 2 Aug 1999 09:38:24 -0400

| Looking at the definition we have for the Unique fact, two things
occur
  | to me:
  | 
  |  - There is no restriction on the timescale of this fact - in other
  | words, it is unclear whether, finding the same Unique fact value on
a
  | server many years later, the file should be assumed to be the
original.

// I think the draft was fairly clear that it lasts only for the
duration
// of the ftp session.   Break the connection and connect again, and the
// unique fact values all come from a new space entirely, and can't be
compared
// with ones for before (which may turn out to be a little annoying for
those
// clients that believe in making a new connection for every command
they issue,
// but killing that behaviour is probably a good thing...)

Right... It really is a Monday, or I'd have read the perfectly clear
text that says exactly that. :-)

  | The wording is clear, however, that
  | changing the contents of a file does not change its unique fact, so,

// does not necessarily change its unique fact - yes (but it could, as
the
// distinction between changing a byte in an existing file, and re-using
a
// file name for an entirely new file with almost identical contents to
the
// one that used to use the name is too subtle for an FTP server to
attempt to
// represent).

("an FTP server" now? Changed your mind, then. :-) )

Yes, I see what you mean... I think that point is sufficiently important
to actually stress somewhere in the document, perhaps?

  | presumably, the fact is only 'useful' if the two Unique facts are
  | compared within a relatively short time period, or with additional
  | comparison of the Size and Modify facts.

// The intent is to allow a server to look at a listing and determine
that
// two file names listed represent the same thing, at that instant.
// It is not meant to provide any kind of information as to the data
which
// forms the contents of the file.
// 
// Perhaps I should say more on this issue?   Does anyone want to
contribute
// some suitable words?

Ho hum... Presumably finding a file "foo" with Unique fact "abc123"
sometime, and, later in the session, finding a file "bar" with Unique
fact "abc123", also implies that the files are identical? Even if "foo"
no longer exists - presumably a rename.

Except that, in the case of UNIX, the device-inode pair of which we're
so fond may have simply been reused... "foo" may have been deleted, and
later the inode on that device used by "bar". And I thought UNIX would
be an easy system to implement the Unique fact on. I really hate to
think how Alun's going to deal with this one.

Now, if the Unique fact is only to be trusted for a single listing, then
we can throw away the problems we're having - especially Alun - and
simply number the files on a per-listing basis.

  | The other thing, which I'm not certain needs any more clarification
than
  | re-reading it some time *other* than Monday morning, is that two
listed
  | names having a different Unique fact may not be different underlying
  | objects. I'm not even really sure that this matters.

// Yes, something more along those lines may be needed as well.

Or a disclaimer of "Do not attempt an implementation of this until after
midday on a Monday following a drunken weekend". :-)

The problem I see is that many of these facts have to be implemented in
wildly differing ways on different platforms, and moreover, each
platform has their own gotchas. I'm beginning to think that a seperate
document on implementing the FTP might be in order, but perhaps that's
over the top for now.

Dave.

---

From: Robert Elz <[email-masked]>
Date: Mon, 2 Aug 1999 10:55:17 -0400

Date:        Mon, 2 Aug 1999 09:38:24 -0400
    From:        Dave Cridland <[email-masked]>
    Message-ID:  <31932F0394A0D111A7420000B45379D42D5E5A@DA-VINCI>

  | ("an FTP server" now? Changed your mind, then. :-) )

Touché

  | Yes, I see what you mean... I think that point is sufficiently important
  | to actually stress somewhere in the document, perhaps?

Sure - send text...

  | Ho hum... Presumably finding a file "foo" with Unique fact "abc123"
  | sometime, and, later in the session, finding a file "bar" with Unique
  | fact "abc123", also implies that the files are identical? Even if "foo"
  | no longer exists - presumably a rename.

It implies that the thing that was foo, in some sense, is the same as
the thing that is bar.  Whether the data is similar is another question,
even if the name hadn't changed, the data isn't guaranteed to be stable
for any period at all.   To find out if foo is still the same thing as
bar, another listing would be needed, if you still get the same unique
fact value, it is, otherwise, it has moved from under you.

  | Except that, in the case of UNIX, the device-inode pair of which we're
  | so fond may have simply been reused... "foo" may have been deleted, and
  | later the inode on that device used by "bar". And I thought UNIX would
  | be an easy system to implement the Unique fact on. I really hate to
  | think how Alun's going to deal with this one.

You're reading too much into the "unique" requirement I think.   Perhaps
more does need to be written about this.

  | Now, if the Unique fact is only to be trusted for a single listing, then
  | we can throw away the problems we're having - especially Alun - and
  | simply number the files on a per-listing basis.

No, it needs to be more than that - we decided not to bother with any
kind of recursive listing, so listing of sub-directories needs to be done
in two separate steps - you do want to be able to tell whether the files
in a sub-directory are the same as any of the ones above (or even in general,
to guard against possible curcular filesystems, which tvfs doesn't want to
occur, but ftp in general says nothing about, to discover if the directory
you're listing is the same one you encountered 5 listings ago).

Basically, what I think needs to be added is something about "on a stable
filestore".   That is, if the underlying filestore isn't altering, the unique
fact will give you the same value for the same file (in the same session - that
requirement is just so ftp servers don't need to maintain stable/shared
storage between invocations of themselves if they have to invent their own
IDs and save them somewhere).

Once the filestore starts changing under the ftp server, all bets are
off, and almost anything can happen.    If I add words like that, will that
make understanding this work any easier do you think?

  | The problem I see is that many of these facts have to be implemented in
  | wildly differing ways on different platforms, and moreover, each
  | platform has their own gotchas.

Yes, absolutely.

  | I'm beginning to think that a seperate
  | document on implementing the FTP might be in order, but perhaps that's
  | over the top for now.

On the latter part, yes ... on the former, perhaps.

kre

---

From: Alun Jones <[email-masked]>
Date: Mon, 2 Aug 1999 15:48:05 -0400

At 09:38 AM 8/2/99 -0400, you wrote: 
The problem I see is that many of these facts have to be implemented in
wildly differing ways on different platforms, and moreover, each platform
has their own gotchas. I'm beginning to think that a seperate document on
implementing the FTP might be in order, but perhaps that's over the top for
now.
<<<<

I've written a few paragraphs that I was thinking might eventually become
an informational RFC on common mistakes made in FTP server and client
implementations, with some clues as to how to avoid them, and why they are
mistakes.

Anyone want to take a look?

Alun.
~~~~

--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find it
1602 Harvest Moon Place | at web site http://www.wftpd.com or email
Cedar Park TX 78613     | us at [email-masked].  VISA / MC accepted.
Fax +1 (512) 378 3246   | NT based ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100.
*WFTPD and WFTPD Pro now available as native Alpha versions for NT*