I did not think the patch series for support of create time was merged yet.
The cifs filesystem can expose the birth time through extended
attributes but as far as I know there is no way to save this on Linux.
Has something changed?
Probably best to ask about this on linux fs-devel mailing list
Copying a file using cp on a NTFS filesystem to an ext4 filesystem does not
copy the birth time:
$ cp --preserve=all ntfs.txt ~
$ stat ~/ntfs.txt
...
Birth: -
-- Enda
--
To unsubscribe from this list: send the line unsubscribe linux-cifs in
the body of a message to
On Fri, Aug 13, 2010 at 10:54:10AM -0700, Jeremy Allison wrote:
On Fri, Aug 13, 2010 at 08:54:32AM -0400, J. Bruce Fields wrote:
On Sun, Aug 08, 2010 at 06:05:01AM -0700, Jeremy Allison wrote:
We don't need to ape Windows in everything.
The coming ACL disaster will show that (we will go
On Mon, Aug 16, 2010 at 02:08:29PM -0400, J. Bruce Fields wrote:
On Fri, Aug 13, 2010 at 10:54:10AM -0700, Jeremy Allison wrote:
On Fri, Aug 13, 2010 at 08:54:32AM -0400, J. Bruce Fields wrote:
On Sun, Aug 08, 2010 at 06:05:01AM -0700, Jeremy Allison wrote:
We don't need to ape Windows
On Fri, 6 Aug 2010 18:58:42 -0500
Steve French smfre...@gmail.com wrote:
On Fri, Aug 6, 2010 at 6:30 PM, Neil Brown ne...@suse.de wrote:
On Thu, 5 Aug 2010 22:55:06 -0500
Steve French smfre...@gmail.com wrote:
On Thu, Aug 5, 2010 at 10:38 PM, Neil Brown ne...@suse.de wrote:
On Thu, 5
On Mon, 2 Aug 2010 10:09:49 -0400
Greg Freemyer greg.freem...@gmail.com wrote:
Furthermore, I'll go ahead and propose the following (simple) semantics:
1) birthtime is initialized to the current time when a new inode is
created
2) it's settable via the xattr to an arbitrary value
On Fri, 30 Jul 2010 14:11:46 -0400
Trond Myklebust trond.mykleb...@fys.uio.no wrote:
On Fri, 2010-07-30 at 13:55 -0400, Phil Pishioneri wrote:
On 7/22/10 2:59 PM, Trond Myklebust wrote:
The fact remains that most of us would be hard pressed to name an
application
Microsoft Office?
On Fri, 30 Jul 2010 23:22:58 +0200
utz lehmann lkml...@s2y4n2c.de wrote:
On Thu, 2010-07-22 at 09:40 -0700, Linus Torvalds wrote:
But the fact is, th Unix ctime semantics are insane and largely
useless. There's a damn good reason almost nobody uses ctime under
unix.
So what I'm
On Sat, 2010-07-31 at 15:03 -0400, Trond Myklebust wrote:
Sigh... So please explain how it would be useful to export that
particular filesystem through _both_ CIFS and NFS?
My point was that in most circumstances you want to export either
through CIFS or through NFS, but very rarely both.
On Friday 2010-07-30 23:22, utz lehmann wrote:
On Thu, 2010-07-22 at 09:40 -0700, Linus Torvalds wrote:
But the fact is, th Unix ctime semantics are insane and largely
useless. There's a damn good reason almost nobody uses ctime under
unix.
So what I'm suggesting is that we have a flag -
On Sat, 2010-07-31 at 10:08 +0200, Jan Engelhardt wrote:
When abusing an existing time stamp use atime not ctime please.
ctime has it's uses. atime was just a mistake and is nearly useless.
MUAs make use of atime.
I know mutt uses atime to detect new messages. But there are better and
more
utz lehmann lkml...@s2y4n2c.de wrote:
When abusing an existing time stamp use atime not ctime please.
ctime has it's uses. atime was just a mistake and is nearly useless.
CacheFiles currently uses atime to determine least-recently-usedness.
David
--
To unsubscribe from this list: send the
On Sat, 2010-07-31 at 12:41 -0600, Andreas Dilger wrote:
On 2010-07-30, at 12:11, Trond Myklebust wrote:
Your Mac has a perfectly functional CIFS client, as do your Linux boxes.
They both interoperate just fine with Samba, and would presumably
continue to do so if someone were to decide to
On Saturday 2010-07-31 21:03, Trond Myklebust wrote:
On Sat, 2010-07-31 at 12:41 -0600, Andreas Dilger wrote:
On 2010-07-30, at 12:11, Trond Myklebust wrote:
Your Mac has a perfectly functional CIFS client, as do your Linux boxes.
They both interoperate just fine with Samba, and would
Neil Brown ne...@suse.de wrote:
This justifies for me why a CIFS client would want to extract the
creation-time from the CIFS protocol, but not why you want to expose it via a
generic interface.
It would also be easier for NFSD if the creation time was in struct kstat.
It's included as an
On Wed, 28 Jul 2010 18:28:02 +0100
David Howells dhowe...@redhat.com wrote:
Neil Brown ne...@suse.de wrote:
ctime and mtime have real cache-coherence semantics which require them being
updated by the kernel (whether the cache is on an NFS client, in a backup
archive, or in a .o
On Thu, 22 Jul 2010 10:24:17 -0700
Linus Torvalds torva...@linux-foundation.org wrote:
Of people can just use xattrs and do it all entirely in user space. I
assume that's what samba does now, even outside of birthtime.
Much as I despise xattrs, this would definitely be my preference.
ctime
On 2010-07-22 at 21:21 -0400 Ted Ts'o sent off:
Well, not POSIX, because POSIX doesn't have CreationTime at all.
BSD's birthtime doesn't allow it to be set, and the question here is
largely philosophical.
actually, it can (partly :). But the way it can be done is an insane hack:
quote
On Thursday 2010-07-22 14:17, Volker Lendecke wrote:
On Thu, Jul 22, 2010 at 01:14:47PM +0100, David Howells wrote:
Jan Engelhardt jeng...@medozas.de wrote:
Linux already has a creation time field, it's called otime (there is no b
in creation), and you will find scattered fragments of that
On Thu, Jul 22, 2010 at 08:14:42AM -0700, Linus Torvalds wrote:
# recent FreeBSD, NetBSD have creation timestamps called birthtime:
AC_CHECK_MEMBERS([struct stat.st_birthtimespec.tv_nsec])
AC_CHECK_MEMBERS([struct stat.st_birthtime], AC_CHECK_MEMBERS([struct
stat.st_birthtimensec]))
On Thursday 2010-07-22 17:14, Linus Torvalds wrote:
It is? It's called crtime in Ext4. st_btime, however, would be compatible
with BSD's stat, and Samba would just use it by way of autoconf magic if it
appeared.
Samba has the following check:
# recent FreeBSD, NetBSD have creation
On Thu, Jul 22, 2010 at 8:36 AM, Volker Lendecke
volker.lende...@sernet.de wrote:
The nice thing about this is also that if this is supposed
to be fully usable for Windows clients, the birthtime needs
to be changeable. That's what NTFS semantics gives you, thus
Windows clients tend to require
On Thu, Jul 22, 2010 at 11:47 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Jul 22, 2010 at 8:36 AM, Volker Lendecke
volker.lende...@sernet.de wrote:
The nice thing about this is also that if this is supposed
to be fully usable for Windows clients, the birthtime needs
to be
On Thu, Jul 22, 2010 at 12:06 PM, Greg Freemyer greg.freem...@gmail.com wrote:
On Thu, Jul 22, 2010 at 11:47 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Jul 22, 2010 at 8:36 AM, Volker Lendecke
volker.lende...@sernet.de wrote:
The nice thing about this is also that if
Jan Engelhardt jeng...@medozas.de wrote:
There just is no way currently to store creation times.
What do you mean? Ext4 and BtrFS can both do so; it's just that there's no
user interface to it.
David
--
To unsubscribe from this list: send the line unsubscribe linux-cifs in
the body of a
On Thursday 2010-07-22 17:47, Linus Torvalds wrote:
On Thu, Jul 22, 2010 at 8:36 AM, Volker Lendecke
volker.lende...@sernet.de wrote:
The nice thing about this is also that if this is supposed
to be fully usable for Windows clients, the birthtime needs
to be changeable. That's what NTFS
On Thu, Jul 22, 2010 at 08:47:46AM -0700, Linus Torvalds wrote:
On Thu, Jul 22, 2010 at 8:36 AM, Volker Lendecke
volker.lende...@sernet.de wrote:
The nice thing about this is also that if this is supposed
to be fully usable for Windows clients, the birthtime needs
to be changeable.
On Thu, 2010-07-22 at 09:40 -0700, Linus Torvalds wrote:
On Thu, Jul 22, 2010 at 9:27 AM, Jeremy Allison j...@samba.org wrote:
On Thu, Jul 22, 2010 at 08:47:46AM -0700, Linus Torvalds wrote:
Tell me why we shouldn't just do this right?
No, ctime isn't the same as Windows create time.
On Thursday 2010-07-22 18:40, Linus Torvalds wrote:
On Thu, Jul 22, 2010 at 9:27 AM, Jeremy Allison j...@samba.org wrote:
On Thu, Jul 22, 2010 at 08:47:46AM -0700, Linus Torvalds wrote:
Tell me why we shouldn't just do this right?
No, ctime isn't the same as Windows create time.
Umm. What
Linus Torvalds wrote:
I personally think that Unix ctime is insane. There is no real reason
why write() should change mtime, but chmod changes ctime. It was
just a random decision way back when...
I believe it was done that way so dump could backup just the inode and not
the data if only
On Thu, Jul 22, 2010 at 10:12 AM, Jim Rees r...@umich.edu wrote:
I believe it was done that way so dump could backup just the inode and not
the data if only the inode had changed. Full history here:
http://blog.plover.com/Unix/ctime.html
Yes, the dump reasoning makes sense, and that history
On Thu, Jul 22, 2010 at 12:58:50PM -0400, Trond Myklebust wrote:
That would make it impossible to export the filesystem with NFSv2 and
v3. They do rely on ctime checking for certain operations (e.g. deciding
when to invalidate access and acl caches). NFSv4 needs this too if the
filesystem
On Thu, Jul 22, 2010 at 11:02:04AM -0700, Jeremy Allison wrote:
On Thu, Jul 22, 2010 at 12:58:50PM -0400, Trond Myklebust wrote:
That would make it impossible to export the filesystem with NFSv2 and
v3. They do rely on ctime checking for certain operations (e.g. deciding
when to
On Thursday 2010-07-22 20:02, Jeremy Allison wrote:
On Thu, Jul 22, 2010 at 12:58:50PM -0400, Trond Myklebust wrote:
That would make it impossible to export the filesystem with NFSv2 and
v3. They do rely on ctime checking for certain operations (e.g. deciding
when to invalidate access and
On Thu, Jul 22, 2010 at 08:05:00PM +0200, Jan Engelhardt wrote:
On Thursday 2010-07-22 20:02, Jeremy Allison wrote:
On Thu, Jul 22, 2010 at 12:58:50PM -0400, Trond Myklebust wrote:
That would make it impossible to export the filesystem with NFSv2 and
v3. They do rely on ctime checking
On Thu, Jul 22, 2010 at 08:04:41PM +0200, Volker Lendecke wrote:
On Thu, Jul 22, 2010 at 11:02:04AM -0700, Jeremy Allison wrote:
On Thu, Jul 22, 2010 at 12:58:50PM -0400, Trond Myklebust wrote:
That would make it impossible to export the filesystem with NFSv2 and
v3. They do rely on
On Thu, Jul 22, 2010 at 10:24:17AM -0700, Linus Torvalds wrote:
And yes, I am also sure that there are applications that do depend on
ctime semantics. Trond mentioned NFS serving, and that's unfortunate.
I bet there are others. That's inevitable when you have 40 years of
history. So I'm not
On Jul. 22, 2010, 21:45 +0300, Greg Freemyer greg.freem...@gmail.com wrote:
On Thu, Jul 22, 2010 at 2:21 PM, Benny Halevy bhal...@panasas.com wrote:
On Jul. 22, 2010, 20:24 +0300, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Jul 22, 2010 at 10:03 AM, Jan Engelhardt
Hi Linus,
My point is that we have three timestamps, and
windows wants three timestamps (somebody claims that NTFS has four
timestamps, but the Windows file time access functions certainly only
shows three times, so any potential extra on-disk times have no
relevance because they are
On Fri, Jul 23, 2010 at 11:03:47AM +1000, tri...@samba.org wrote:
The other big difference from POSIX timestamps is that the
CreationTime is settable on Windows, and some of the windows UI
behaviour relies on this.
Well, not POSIX, because POSIX doesn't have CreationTime at all.
BSD's
Hi Ted,
Does it literally mean file creation time in terms of when the OS
created the file, or does it mean file in the sense of
application contents. For example, if an application edits the
file and saves it out using write file to foo.new; sync; rename
foo to foo.bak; rename foo.new
On Mon, Jul 19, 2010 at 9:15 AM, David Howells dhowe...@redhat.com wrote:
Linus Torvalds torva...@linux-foundation.org wrote:
- that whole xstat buffer handling is just a mess. I think you
already fixed the xstat_parameters crud and just made it a simple
unsigned long and a direct argument,
On Mon, Jul 19, 2010 at 10:26 AM, David Howells dhowe...@redhat.com wrote:
Ask your samba people, for example, if they'd _ever_ do just a xstat()?
I suspect they would, though maybe they can say otherwise. What about SMB
directory enumeration? I believe that is effectively
On Saturday 17 July 2010 07:51:30 Mark Harris wrote:
David Howells wrote:
With a 2:2 split between exponent
(tv_gran_units) and mantissa (tv_granularity), you can do:
UNITSECONDS/UNITEXPONENTMANTISSA
nanoseconds 0.1 -9 1
Mark Harris m...@osj.us wrote:
struct xstat_time {
unsigned long long tv_sec, tv_nsec;
};
unsigned? Existing filesystems support on-disk timestamps
representing times prior to the epoch.
I suppose it doesn't hurt to make is signed. It's large enough...
Looking at it again,
On Friday 16 July 2010, David Howells wrote:
Mark Harris m...@osj.us wrote:
So how about using up the dead space for what Steve French wanted:
| One hole that this reminded me about is how to return the superblock
| time granularity (for NFSv4 this is attribute 51 time_delta
Arnd Bergmann a...@arndb.de wrote:
You could also define the tv_gran_units to be power-of-ten nanoseconds,
making it a decimal floating point number like
enum {
XSTAT_NANOSECONDS_GRANULARITY = 0,
XSTAT_MICROSECONDS_GRANULARITY = 3,
XSTAT_MILLISECONDS_GRANULARITY = 6,
On Friday 16 July 2010, David Howells wrote:
Arnd Bergmann a...@arndb.de wrote:
You could also define the tv_gran_units to be power-of-ten nanoseconds,
making it a decimal floating point number like
enum {
XSTAT_NANOSECONDS_GRANULARITY = 0,
Arnd Bergmann a...@arndb.de wrote:
For the volume id, I could not find any file system that requires more
than 32 bytes here, which is also reasonable to put into the structure.
Make it 36 if you want to cover ascii encoded UUIDs.
You should also include a length. Volume IDs may be
David Howells wrote:
With a 2:2 split between exponent
(tv_gran_units) and mantissa (tv_granularity), you can do:
UNITSECONDS/UNITEXPONENTMANTISSA
nanoseconds 0.1 -9 1
microseconds0.01-6 1
On Thursday 15 July 2010 04:17:12 David Howells wrote:
(10) Can be extended by using more request flags and tagging further data
after
the end of the standard return data. Such things as the following could
be returned:
- BSD st_flags or FS_IOC_GETFLAGS.
-
Add a pair of system calls to make extended file stats available, including
file creation time, inode version and data version where available through the
underlying filesystem.
[This depends on the previously posted pair of patches to (a) constify a number
of syscall string and buffer arguments
52 matches
Mail list logo
