Subject: Ftp-WG: MLST-07

From: Dave Cridland <[email-masked]>
Date: Mon, 2 Aug 1999 08:12:42 -0400

I've been using device:inode pairs, which seems to work. (Actually with
a '-' seperator). These are unique across a machine, however possibly
(and therefore, with my luck, probably) don't work for files being
served from a network-mounted filesystem (NFS and the like).

I'm wholly unsure what I'd use under Windows, however... I suspect I'd
try for something based on machine:dos-path pairs, possibly encoded with
something, but these would, as you say, get rather big. Given that any
multiple names for single objects is, presumably, done by the FTP
server, however, there might be scope for some kind of lookup table,
scary as this may sound. If there's no multiple names for files even
within the server, I'd simply drop the fact, of course.

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 assume that should two files both exist at the same time with the same
Unique fact, then they are the same file. (Feel free to change "file"
for "directory" or "Object"). The wording is clear, however, that
changing the contents of a file does not change its unique fact, so,
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 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.

-----Original Message-----
From: Alun Jones [mailto:[email-masked]]
Sent: Friday, July 30, 1999 1:04 PM
To: FTPEXT Working Group
Subject: Ftp-WG: MLST-07

At 12:37 AM 7/30/99 -0400, Stephen Tihor <[email-masked]>
wrote:
>Wouldn't a suitably qualified MS-DOS short name path be useful as 
>a unqiue fact for short and long named files in the windows version. 

You mean the whole path?  Up to 256 characters of it, possibly including
semicolons [and the escaping thereof]?  I'm sorry, I missed out the
adjective "reasonable" from my posting. :-)

It'd be interesting, however, to note what other people are using on
other
platforms to generate their 'unique' fact - for instance, those using
inodes, how does your solution cope with more than one drive, in which
case
any number of files would share the same inode, just on different
mounts,
right?  [It's been a while since I was seriously into Unix, sorry]

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*

---

From: Robert Elz <[email-masked]>
Date: Mon, 2 Aug 1999 08:32:58 -0400

Date:        Mon, 2 Aug 1999 08:12:42 -0400
    From:        Dave Cridland <[email-masked]>
    Message-ID:  <31932F0394A0D111A7420000B45379D42D5E58@DA-VINCI>

  | I've been using device:inode pairs, which seems to work. (Actually with
  | a '-' seperator). These are unique across a machine, however possibly
  | (and therefore, with my luck, probably) don't work for files being
  | served from a network-mounted filesystem (NFS and the like).

I considered that - and considered using the file system ID that NFS
has instead of the device (major/minor) number - but on all the systems
I have access to, the kernel seems to fake a reasonable enough device
number pair for NFS mounted filesystems that it all just works this way,
so I also decided to stick to the dev_t & ino_t pair (then encoded in a
way that it looks pretty meaningless - even when you know what it represents)

  | I'm wholly unsure what I'd use under Windows,

I know nothing at all about windows or dos, but it has always seemed to me
that the filesystem is a pretty low level thing there.  Do they not let you
know (or discover without too much work) what the block number of the first
block of the file is, or anything like that?   Some data of that kind, along
with the filesystem name (C: etc) would serve just fine - if it is available.

  | 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...)

  | 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).

  | 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?

  | 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.

kre