file creation times ?

[Arun Sharma]

Is there any reason why FreeBSD doesn't store file creation times on
the disk (apart from historical reasons) ?

-Arun


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Aleksandr A.Babaylov]

Arun Sharma writes:
> Is there any reason why FreeBSD doesn't store file creation times on
> the disk (apart from historical reasons) ?
in adddition to atime, ctime and mtime?

-- 
@BABOLO  http://links.ru/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Arun Sharma]

On Thu, May 18, 2000 at 09:04:52PM +0400, Aleksandr A.Babaylov wrote:
> Arun Sharma writes:
> > Is there any reason why FreeBSD doesn't store file creation times on
> > the disk (apart from historical reasons) ?
> in adddition to atime, ctime and mtime?

struct timespec st_atimespec;  /* time of last access */
struct timespec st_mtimespec;  /* time of last data modification */
struct timespec st_ctimespec;  /* time of last file status change */ 

None of them tell me when the file was created.

-Arun


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Peter Jeremy]

On Thu, 18 May 2000 10:35:11 -0700, Arun Sharma <[EMAIL PROTECTED]> wrote:

>On Thu, May 18, 2000 at 09:04:52PM +0400, Aleksandr A.Babaylov wrote:
>> Arun Sharma writes:
>> > Is there any reason why FreeBSD doesn't store file creation times on
>> > the disk (apart from historical reasons) ?

To put it another way, why _should_ FreeBSD store a file creation time?

>> in adddition to atime, ctime and mtime?
>
>struct timespec st_atimespec;  /* time of last access */
>struct timespec st_mtimespec;  /* time of last data modification */
>struct timespec st_ctimespec;  /* time of last file status change */ 
>
>None of them tell me when the file was created.

That's all Unix has ever offered (both the original AT&T FS and
FFS/UFS).  If you really need a file creation time, you'll need a
different filesystem.

Peter


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Arun Sharma]

On Thu, May 25, 2000 at 11:03:38AM +1000, Peter Jeremy wrote:
> On Thu, 18 May 2000 10:35:11 -0700, Arun Sharma <[EMAIL PROTECTED]> wrote:
> 
> >On Thu, May 18, 2000 at 09:04:52PM +0400, Aleksandr A.Babaylov wrote:
> >> Arun Sharma writes:
> >> > Is there any reason why FreeBSD doesn't store file creation times on
> >> > the disk (apart from historical reasons) ?
> 
> To put it another way, why _should_ FreeBSD store a file creation time?

0. I'm tired of seeing people putting "Created: mm/dd/yy" in their documents.
1. NTFS does it. It's a part of SMB. I suspect that Samba just uses the
   last modified time.
2. An average computer user would expect it. I didn't know that UNIX didn't
   keep track of file creation times 5-6 years after I started using it.

> That's all Unix has ever offered (both the original AT&T FS and
> FFS/UFS).  If you really need a file creation time, you'll need a
> different filesystem.

I know. That's why I ask. So if someone designs a ext3fs killer journalling
filesystem for BSD, would they consider adding it :) ?

-Arun


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Peter Jeremy]

On 2000-May-25 11:59:41 +1000, Arun Sharma <[EMAIL PROTECTED]> wrote:
>On Thu, May 25, 2000 at 11:03:38AM +1000, Peter Jeremy wrote:
>> To put it another way, why _should_ FreeBSD store a file creation time?
>
>0. I'm tired of seeing people putting "Created: mm/dd/yy" in their documents.

- UFS stores a UID for each file, but that doesn't stop
  "Author: J. Bloggs" in documents.  Why would storing a creation
  timestamp be any different?
- How do you determine the creation time of a file when it's printed?
- If I make a copy of an existing file, was the new file created
  when the original file was created or when I did the copy?

>1. NTFS does it. It's a part of SMB.

That's not justification for putting a creation time into the UFS.
Different filesystems store different information - depending on
what the FS developers saw as important.  You could just as easily
point out the deficiencies of NTFS based on it's inability to
support all the metadata in NFS.

> I suspect that Samba just uses the last modified time.

According to the SAMBA documentation, it uses the earliest of the 3
timestamps that are available.  (Or can be told to fake a creation
time of 1980-JAN-01  on directories).

Transferring file metadata between systems is always problematic.
Generally the metadata translation layer does the best it can and
fakes the rest.  For example, NTFS access and modification timestamps
can't be translated to Unix timestamps without knowing the location
(timezone) where the NTFS file was last modified/accessed.

>2. An average computer user would expect it. I didn't know that UNIX didn't
>   keep track of file creation times 5-6 years after I started using it.

If it took you 5-6 years to notice that the creation time _wasn't_
stored, the creation time can't have been that important to you.  (And
I haven't previously run into anyone else who wanted a creation time,
so the expectation can't be that widespread).

> So if someone designs a ext3fs killer journalling
>filesystem for BSD, would they consider adding it :) ?

Adding a creation timestamp would add 4 or 8 bytes of metadata
to each file, as well as requiring additional code (and CPU time)
to manage it.  A 6th Edition inode was 32 bytes (and only stored
access and modify times).  A FreeBSD inode is already 4 times as
big.  It's necessary to strike a balance between storing every
possible piece of information about a file and the amount of
space/time used to store/manage this metadata.

A modification timestamp is essential to support incremental backups.
Splitting it into separate data and metadata timestamps meets POLA
(users generally want 'modification' to mean that the content changed,
not that the file was renamed).  Access timestamps are important for
filespace management (knowing what files aren't used and can therefore
be archived or deleted).

As far as I'm concerned, you still haven't demonstrated any real
need or justification for a creation timestamp.  That said,
there's nothing stopping you adding a creation timestamp to the
UFS and providing patches.

Peter


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Brian Somers]

[.]

> Adding a creation timestamp would add 4 or 8 bytes of metadata
> to each file, as well as requiring additional code (and CPU time)
> to manage it.  A 6th Edition inode was 32 bytes (and only stored
> access and modify times).  A FreeBSD inode is already 4 times as
> big.  It's necessary to strike a balance between storing every
> possible piece of information about a file and the amount of
> space/time used to store/manage this metadata.

I'm not advocating adding a creation time, but had it been done when 
the ufs/ffs was designed I think it would be a nice thing - *but* I 
suspect the correct place to store it is in the directory itself 
along with the inode number and file name.

> A modification timestamp is essential to support incremental backups.
> Splitting it into separate data and metadata timestamps meets POLA
> (users generally want 'modification' to mean that the content changed,
> not that the file was renamed).  Access timestamps are important for
> filespace management (knowing what files aren't used and can therefore
> be archived or deleted).

Of course access timestamps are usually useless anyway as most (?!!) 
people will back up their system from time to time OOPS !  I 
never realised before now - dump *doesn't* update the access time.  
This is *really* excellent :-)  Scratch this comment about access 
times being useless !

> As far as I'm concerned, you still haven't demonstrated any real
> need or justification for a creation timestamp.  That said,
> there's nothing stopping you adding a creation timestamp to the
> UFS and providing patches.

This should be trivial if added to the directory itself and should be 
fully ``option''d in the kernel :-)  I think it would be useful to some.

Of course doing it in the directory would make it a pretty much 
one-way option, so if the work was done, it would be most appropriate 
to have the capability included as some sort of newfs/tunefs option.  
If the format of the directory with this option enabled became 
/ then the code could allow non-creation-time 
filesystems to be mounted as creation-time filesystems and could 
just add the timestamp to new files (by asserting that the existence 
of the '/' means there's a timestamp next).

> Peter

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Don Lewis]

On May 24,  6:58pm, Arun Sharma wrote:
} Subject: Re: file creation times ?
} On Thu, May 25, 2000 at 11:03:38AM +1000, Peter Jeremy wrote:
} > To put it another way, why _should_ FreeBSD store a file creation time?
} 
} 0. I'm tired of seeing people putting "Created: mm/dd/yy" in their documents.

When saving a document to "file", many editors will do the equivalent of
save document to "file.new"
ln "file" "file.bak"
mv "file.new" "file"
in order to minimize the possibility of losing the document if the editor
or the system crashes at just the wrong time.  The result of this would
be to set the file creation time to the time it was last saved.  This
won't be very helpful if you are relying on the file creation time to
tell you when the *document* was first created.

NFS doesn't support this file timestamp, so you lose if the file is stored
on another server.

The tar archive format doesn't support this timestamp, so a document that
is archived using tar and later restored will lose its notion of when it
was created.

What should the semantics of the creation time be across a backup and
restore?  Should the original creation time be restored, or should the
creation time be the time when the restored copy of the file is written?
What about just copying a file?  If I make an exact copy of a document,
should the two copies have the same or differing creation times?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Christoph Sold]

Don Lewis wrote:

> On May 24,  6:58pm, Arun Sharma wrote:
> } Subject: Re: file creation times ?
> } On Thu, May 25, 2000 at 11:03:38AM +1000, Peter Jeremy wrote:
> } > To put it another way, why _should_ FreeBSD store a file creation time?
> }
> } 0. I'm tired of seeing people putting "Created: mm/dd/yy" in their documents.
>
> When saving a document to "file", many editors will do the equivalent of
> save document to "file.new"
> ln "file" "file.bak"
> mv "file.new" "file"
> in order to minimize the possibility of losing the document if the editor
> or the system crashes at just the wrong time.  The result of this would
> be to set the file creation time to the time it was last saved.  This
> won't be very helpful if you are relying on the file creation time to
> tell you when the *document* was first created.

To answer the question who needs this: Apple Macintosh MFS filesystems (long died
since the MacPlus) introduced the file creation date, and it lives on since then in
Apples HFS and HFS+ Filesystems. I found the information handy when searching for
files.

[snippety]

> What should the semantics of the creation time be across a backup and
> restore?  Should the original creation time be restored, or should the
> creation time be the time when the restored copy of the file is written?
> What about just copying a file?  If I make an exact copy of a document,
> should the two copies have the same or differing creation times?

To solve these questions (along with the one shown above in code), Apple has a
"Swap File Info" call. This way,

read document;
save document to file.tmp;
[work on the document, saving to the tempfile as you whish]
[when the user say to save now:]
save document to file.tmp;
exchange file info records of file.tmp and document;
{optionally rename file.tmp to document.bak -- remember, file info was swapped
before}

Now everything else is easy: after a backup, the file creation time is the time the
file was originally created (not the restored copy's creation time). A copied file
is created when you copy it. Exact copies should have different creation times.
That's the way HFS does it -- other opinions welcome. I like it this way.

If somebody can dream up an implementation in FFS, I'd love to see it realized (and
have some good use for it, since I tend to remember when something started...).

Hope this clarifies the topic a little
-Christoph Sold



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times?

[Brian McGovern]

> 0. I'm tired of seeing people putting "Created: mm/dd/yy" in their docuemnts.

Ok, so stop them.

> 1. NTFS does it. It's a part of SMB. I suspect that Samba just uses the
>   last modified time.

Just because NTFS does it, doesn't mean its right, or even valid. See below.

> 2. The average computer user would expect it. I didn't know that UNIX didn't
>   keep track of file creation times 5-6 years after I started using it.

Well, you just proved how useless a feature it tends to be.

The problem with "file creation time" is that its potentially misleading. Thats
one of the reasons its called "file modification time".

Take, for example, the case where someone pulls up a file, edits one word,
and saves it. In those cases, the distinction between creation and modification
time _may_ be remotely useful.

However, given that the same user could open the file, replace the entire 
contents, and close it, you have to ask the question... Did they modify the
file, or create a new one? The result is that there is no functional difference
between deleting the old file and creating the new one, or just overwriting the
old one with new data. One could argue, therefore, that the file 'creation'
date is the same as the last modification date, as thats when the current 
contents of the file was 'created'.

All-in-all, something along the lines of "inode allocated timestamp" is 
probably not all that useful.
-Brian


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times?

[Christoph Sold]

Brian McGovern wrote:

> > 0. I'm tired of seeing people putting "Created: mm/dd/yy" in their docuemnts.
>
> Ok, so stop them.
>
> > 1. NTFS does it. It's a part of SMB. I suspect that Samba just uses the
> >   last modified time.
>
> Just because NTFS does it, doesn't mean its right, or even valid. See below.

If FFS does it not, it does nto mean it's invalid.

> > 2. The average computer user would expect it. I didn't know that UNIX didn't
> >   keep track of file creation times 5-6 years after I started using it.
>
> Well, you just proved how useless a feature it tends to be.

I disagree.

> The problem with "file creation time" is that its potentially misleading. Thats
> one of the reasons its called "file modification time".

That's one of the reasons why there is both a file creation time as well as a file
modification time.

> Take, for example, the case where someone pulls up a file, edits one word,
> and saves it. In those cases, the distinction between creation and modification
> time _may_ be remotely useful.
>
> However, given that the same user could open the file, replace the entire
> contents, and close it, you have to ask the question... Did they modify the
> file, or create a new one? The result is that there is no functional difference
> between deleting the old file and creating the new one, or just overwriting the
> old one with new data. One could argue, therefore, that the file 'creation'
> date is the same as the last modification date, as thats when the current
> contents of the file was 'created'.
>
> All-in-all, something along the lines of "inode allocated timestamp" is
> probably not all that useful.

I disagree. The file creation time will tell when this particular document has been
created. Useful for "give me everything created after/before" searches. The file
modification time tells me when this document was changed the last time. The file
access time tells me when somebody used the file the last time. That's three
different times, and all have valid uses.

Please see my other posting about this topic, too.

-Christoph Sold



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Brian Somers]

> On May 24,  6:58pm, Arun Sharma wrote:
> } Subject: Re: file creation times ?
> } On Thu, May 25, 2000 at 11:03:38AM +1000, Peter Jeremy wrote:
> } > To put it another way, why _should_ FreeBSD store a file creation time?
> } 
> } 0. I'm tired of seeing people putting "Created: mm/dd/yy" in their documents.
> 
> When saving a document to "file", many editors will do the equivalent of
>   save document to "file.new"
>   ln "file" "file.bak"
>   mv "file.new" "file"
[.]

Such editors are broken.  What if the file is a symlink ?  IMHO 
open() write() write() write() ftruncate() close() is the only way.
-- 
Brian <[EMAIL PROTECTED]>
  <http://www.Awfulhak.org>   
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[sthaug]

> Such editors are broken.  What if the file is a symlink ?  IMHO 
> open() write() write() write() ftruncate() close() is the only way.

If that is the only way, then emacs is of course broken. (And I
disagree - I use emacs every day...)

Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Peter Jeremy]

On 2000-May-26 04:37:48 +1000, [EMAIL PROTECTED] wrote:
>> Such editors are broken.  What if the file is a symlink ?  IMHO 
>> open() write() write() write() ftruncate() close() is the only way.
>
>If that is the only way, then emacs is of course broken. (And I
>disagree - I use emacs every day...)

The behaviour in emacs is (of course) customisable.  Check out
'info emacs Backup Copying'.  You can pick whether the backup
is the physical original, or a copy of it.  (Emacs also understands
symlinks, hardlinks and differences in ownership).

Peter


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Peter Jeremy]

On 2000-May-25 19:03:56 +1000, Brian Somers <[EMAIL PROTECTED]> wrote:
>Of course access timestamps are usually useless anyway as most (?!!) 
>people will back up their system from time to time OOPS !  I 
>never realised before now - dump *doesn't* update the access time.  

This is because dump bypasses the filesystem (it reads the underlying
device).  Therefore the filesystem doesn't see the access.

Other backup tools (tar, pax, cpio etc) access the files through the
FS amd therefore alter the access time.  Some have the ability to
reset the access time afterwards - but that updates the change time,
which is probably worse.  This is probably good justification for a
O_NOTACCESS (ie, this isn't a real access) flag on open(2) to request
that the access time isn't updated.

In general, access time is probably the least important of the
timestamps.  This is reflected in the treatment of access time
updates - unlike all other inode updates, they are not written
synchronously (non-softupdates) and don't affect soft-updates
write-ordering (so atime updates can be lost).

As I see it, the major use of access times would be for a true
hierarchical storage manager (which transparently migrated un-
referenced files to a tape-library or similar).  It's also good
for things like deleting `old' files in /tmp.

>> As far as I'm concerned, you still haven't demonstrated any real
>> need or justification for a creation timestamp.  That said,
>> there's nothing stopping you adding a creation timestamp to the
>> UFS and providing patches.
>
>This should be trivial if added to the directory itself and should be 
>fully ``option''d in the kernel :-)

I think the kernel changes would be fairly trivial, but there'd need
to be fairly extensive userland changes.  And you'd need to change
various archive formats (tar, dump, ...) to support it.

>If the format of the directory with this option enabled became 
>/ then the code could allow non-creation-time 
>filesystems to be mounted as creation-time filesystems and could 
>just add the timestamp to new files (by asserting that the existence 
>of the '/' means there's a timestamp next).

I'm not sure what you mean here.  Are you suggesting that the d_name
begins '/' where  is a binary timestamp?  This sounds
horrible.  If we did go down this path, my preference would be
something like:

union direct {
struct direct_old   o;
struct direct_new   n;
};

struct  direct_old {
u_int32_t d_ino;/* inode number of entry */
u_int16_t d_reclen; /* length of this record */
u_int8_t  d_type;   /* file type, see below */
u_int8_t  d_namlen; /* length of string in d_name */
char  d_name[MAXNAMLEN + 1];/* name with length <= MAXNAMLEN */
};

struct  direct_new {
u_int32_t d_ino;/* inode number of entry */
u_int16_t d_reclen; /* length of this record */
u_int8_t  d_type;   /* file type, see below */
u_int8_t  d_namlen; /* length of string in d_name */
u_int32_t d_crtime; /* Entry creation time */
u_int32_t d_crtimensec; /* Entry creation time */
char  d_name[MAXNAMLEN + 1];/* name with length <= MAXNAMLEN */
};

Where the top bit of d_type choses between them (if set then it's
a new style entry).

Peter


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Brian Somers]

> > Such editors are broken.  What if the file is a symlink ?  IMHO 
> > open() write() write() write() ftruncate() close() is the only way.
> 
> If that is the only way, then emacs is of course broken. (And I
> disagree - I use emacs every day...)

Now there's an argument waiting to happen :-)

So if you create a file and make it writable by me and I edit it, it 
becomes mine ?  Good ol' emacs !  I would guess that in real life it 
*must* be smart enough not to do this (I don't have access to emacs 
from here right now).

> Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[sthaug]

> > > Such editors are broken.  What if the file is a symlink ?  IMHO 
> > > open() write() write() write() ftruncate() close() is the only way.
> > 
> > If that is the only way, then emacs is of course broken. (And I
> > disagree - I use emacs every day...)
> 
> Now there's an argument waiting to happen :-)
> 
> So if you create a file and make it writable by me and I edit it, it 
> becomes mine ?  Good ol' emacs !  I would guess that in real life it 
> *must* be smart enough not to do this (I don't have access to emacs 
> from here right now).

emacs is of course much smarter, and it's also customizable. I was just
reacting to the blanket statement that "open() write() write() write()
ftruncate() close() is the only way".

Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Aleksandr A.Babaylov]

Peter Jeremy writes:
> On 2000-May-25 19:03:56 +1000, Brian Somers <[EMAIL PROTECTED]> wrote:
> >Of course access timestamps are usually useless anyway as most (?!!) 
> >people will back up their system from time to time OOPS !  I 
> >never realised before now - dump *doesn't* update the access time.  
> 
> This is because dump bypasses the filesystem (it reads the underlying
> device).  Therefore the filesystem doesn't see the access.
> 
> Other backup tools (tar, pax, cpio etc) access the files through the
> FS amd therefore alter the access time.  Some have the ability to
> reset the access time afterwards - but that updates the change time,
> which is probably worse.  This is probably good justification for a
> O_NOTACCESS (ie, this isn't a real access) flag on open(2) to request
> that the access time isn't updated.
I check it in FreeBSD 4.0-R
open do not change atime.

> In general, access time is probably the least important of the
> timestamps.  This is reflected in the treatment of access time
> updates - unlike all other inode updates, they are not written
> synchronously (non-softupdates) and don't affect soft-updates
> write-ordering (so atime updates can be lost).
> 
> As I see it, the major use of access times would be for a true
> hierarchical storage manager (which transparently migrated un-
> referenced files to a tape-library or similar).  It's also good
> for things like deleting `old' files in /tmp.
See ports/18813: new port: misc/deleted
this daemon uses access times 

[skip].

-- 
@BABOLO  http://links.ru/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Marco van de Voort]

> That's not justification for putting a creation time into the UFS.
> Different filesystems store different information - depending on
> what the FS developers saw as important.  You could just as easily
> point out the deficiencies of NTFS based on it's inability to
> support all the metadata in NFS.

I know very little of filesystems, but I know that NTFS is extensible 
(and supports several file strains). So probably that is not a limitation of NTFS,
but of the NT implementation of it.

E.g. Mac stuff is stored in an extra strain, extra attributes can be stored in 
the MFS etc etc.  One could write a *nix NTFS driver that supported NFS 
metadata.
Marco van de Voort ([EMAIL PROTECTED] or [EMAIL PROTECTED])




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Brian Somers]

[.]
> I check it in FreeBSD 4.0-R
> open do not change atime.

Indeed, but it sets a bunch of flags that can be referred to later by 
the driver.  This would be a good flag - perhaps limited in the same 
way that touching the file is (owner only).

[.]
> -- 
> @BABOLO  http://links.ru/

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file creation times ?

[Marco van de Voort]

> I know very little of filesystems, but I know that NTFS is extensible 
> (and supports several file strains). So probably that is not a limitation of NTFS,
> but of the NT implementation of it.
> 
> E.g. Mac stuff is stored in an extra strain, extra attributes can be stored in 
> the MFS etc etc.  One could write a *nix NTFS driver that supported NFS 
> metadata.

Whoops, that should be MFT (Master File Table) not MFS. 
Probably got confused by all those MFS messages :-)

And btw there is afaik also no reason why a new NTFS driver couldn't be 
developped for NT (that supported NFS metadata). NTFS support is according
to the docs a separate module. (but that is the theory, not practice)
Marco van de Voort ([EMAIL PROTECTED] or [EMAIL PROTECTED])




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message