Even though the timestamps are filesystems specific implementation, following are the main timestamps which all Linux filesystems have.
ctime – The ctime (change time) is the time when changes made to the file’s inode (owner, permissions, etc.). The ctime is also updated when the contents of a file change. You can view the ctime with the ls -lc command
atime – The atime (access time) is the time when the data of a file was last accessed. Displaying the contents of a file or executing a shell script will update a file’s atime, for example. You can view the atime with the ls -lu command
mtime – The mtime (modify time) is the time when the actual contents of a file was last modified. This is the time displayed in a long directory listing (ls -l)
For more clarity on timestamps:
cat file # file's atime is updated
chmod 755 file # file's ctime is updated
echo "new contents" >> file # file's ctime and mtime are updated
vi file # if you add/delete some lines ctime and mtime will get updated
Following are the system calls for retrieving information about a file
These system calls differ only in the way that file is passed. stat() returns information about the named file. lstat() is also doing the same but if the named file is a link, the information about the link itself will return rather than the file to which the link points. fstat() returns information about a file referred to by an open file descriptor.
The ext4 filesystem have implemented few more timestamps which are following:
dtime – deletion time
crtime – creation time
You can read more about ext4 timestamps in following link:
As Claudio (GOOGLE) mentioned in the above video, (http://youtu.be/zJVCKvXtHtE?t=12m18s), we need to use some logic (client library) to sort your crendentials for reusing. Other wise on every execution of ‘quickstart.py’ script, you need human interaction for getting tokens. I added 6 lines to google’s ‘quickstart.py’ to keep authorization code for reusing. So as long as the user has not revoked the access granted initially to the application, you don’t need a human interaction.
So, you got the idea how to deal with Google API and authentication to Google drive without human interaction. Now, you just need to apply your modifications to the script, suitable to your environment and then just put a cron job.
$* and $@, both these bash special variables expands to the positional parameters, starting from the first one.
These variables are same (expand positional parameters in same way) when using without double quotes. If these variables are using inside double quotes, it will expand positional parameters differently.
$* within double quotes ("$*") is equivalent to the list of positional parameters, separated by IFS variable.
Suppose IFS is ":" and hence expansion of "$*" will be like "$1:$2:$3:…"
And $@ within a pair of double quotes ("$@") is equivalent to the list of positional parameters separated by unquoted spaces, i.e., "$1" "$2".."$N". Or in other words, it is equivalent to the list of positional parameters where each parameters are double quoted.
For sake better understanding I wrote a script named star_and_at.sh and pushed to my public github repo
You can clone my bash github public repository directly using following command
/proc is very special in that it is also a virtual filesystem. It’s sometimes referred to as a process information pseudo-file system. In /proc there is a file named filesystems. And as the name says, it contains what all filesystems that are supported by the running kernel.
Data in MySQL is stored in files (or memory) using a variety of different techniques. Each of these techniques employ different storage mechanisms, indexing facilities, locking levels and ultimately provide a range of different functions and capabilities. By choosing a different technique you can gain additional speed or functionality benefits that will improve the overall functionality of your application.
Comparison between the MyISAM and InnoDB storage engines of MySQL.
does not support transactions
foreign key constraints
no foreign key constraints
row count is not stored internally and so slow COUNT(*)s
row count is stored internally and so fast COUNT(*)s
automatic crash recovery
no automatic crash recovery, but it does offer repair table functionality
stores both data and indexes in one file
stores indexes in one file and data in another
uses a buffer pool (innodb_buffer_pool_size) to cache both data and indexes
uses key buffers (key_buffer) for caching indexes and leaves the data caching management to the operating system
ACID(Atomicity, Consistency, Isolation and Durability) compliant