Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
That's not crtime - even on ext4.
The crtime is maintained (in ext4), but I don't think there is a (convenient) means of extracting it (yet). If you get a files inode (say 9999), you can do this against the filesystem itself (include the < >)
@PTrenholme: as syg00 said: that's change time (ctime), not crtime!
Oops! My bad! (Again.) One of these days I need to learn how to read better.
There is a B option in the find command, but -- on my Fedora system using an ext4 system -- I get this:
$ find ./ -newerBt "yesterday"
find: This system does not provide a way to find the birth time of a file.
find: invalid predicate `-newerBt'
so that's not much help.
The debugfs suggestion works for ext4, but I don't think that it would work for a ntfs file, since the NTFS doesn't actually have an inode. When I tried it, I got this:
$ ls -i /Vista/Users/
25503 All Users 25504 Default User 63970 Judy 15441 Public
15405 Default 25502 desktop.ini 217 Peter
$ sudo debugfs -R 'stat <217>' /dev/sda3
debugfs 1.41.10 (10-Feb-2009)
/dev/sda3: Bad magic number in super-block while opening filesystem
stat: Filesystem not open
Debugfs is part of e2fsprogs - I wouldn't expect it to work on any other f/s; sorry if I wasn't clear on that. Merely offered to prove the data is there.
There have been rumblings on lkml to get the data out, but it would involve other code changes all over the place.
And occupy more in kernel space - which the devs are dead against anytime.
... since the NTFS doesn't actually have an inode. When I tried it, I got this...
I did the same on an ntfs-3g mounted volume and got the same error.
Actually I got the crtime squeezed out of NTFS with a little util called ntfsinfo.
The only problem was that my mounted volume would only be probable with the -f force option, and this marked the NTFS volume as "dirty". Next time I booted the volume under Windows, chkdsk came up...
Very unsatisfying that you can only probe for crtime from Linux on offline/unmounted NTFS volumes...
NTFS is Microsoft proprietary. It is not a Linux filesystem, nor are its internal released publicly.
You're lucky it's supported at all - maybe you should offer some assistance to the linux-ntfs project to include it rather than moan about it.