search for: ctime

I've been working on a patchset to change how the inode->i_ctime is accessed in order to give us conditional, high-res timestamps for the ctime and mtime. struct timespec64 has unused bits in it that we can use to implement this. In order to do that however, we need to wrap all accesses of inode->i_ctime to ensure that bits used as flags are appropriately han...

struct timespec64 has unused bits in the tv_nsec field that can be used for other purposes. In future patches, we're going to change how the inode->i_ctime is accessed in certain inodes in order to make use of them. In order to do that safely though, we'll need to eradicate raw accesses of the inode->i_ctime field from the kernel. Add new accessor functions for the ctime that we can use to replace them. Signed-off-by: Jeff Layton <jlayton...

...l.c:466 scan_thread: Ooh, something changed / timeout [Kdevcentos5x64*CLI> -- Playing '/tmp/smvoice.28537_0' (escape_digits=0123456789#) (sample_offset 0) ? [Kdevcentos5x64*CLI> [Feb 3 17:14:37] WARNING[28468]: pbx_spool.c:461 scan_thread: atime: 1233699276, mtime: 1233699268, ctime: 1233699268 last: 1233699268 next: 1233699278 now: 1233699277 [Kdevcentos5x64*CLI> [Feb 3 17:14:38] WARNING[28468]: pbx_spool.c:461 scan_thread: atime: 1233699276, mtime: 1233699268, ctime: 1233699268 last: 1233699268 next: 1233699278 now: 1233699278 [Kdevcentos5x64*CLI> [Feb 3 17:14:39...

Hi, We use an rsync (rrsync, to be precise) based back-up solution. Every so often an iSCSI based file-system gets brought up and left connected for the night. After a mount event rsync will back that volume up, including server TB of data that haven't been modified, but the ctime is newer than the mtime. Is there a way to stop this behaviour? Cheers, Andrej

It looks like I need to elaborate further to get a feedback. I checked the rsync source code and it is using utime() to restore atime file attribute. It is fine to change ctime for that transferred file in this case. What we are having problem is that when rsync gets kicked off and transfers one file to the destination, this action changes ctime of "all" files in the same directory and sub directories on the destination side, even though a ctime for those...

(R 2.8.0 on Debian GNU/Linux sid) ?file.info contains: mtime, ctime, atime: integer of class '"POSIXct"': file modification, creation and last access times. This implies that ctime is "file [...] creation [...] time" Has R implemented ctime differently to Unix? I understand, on Linux at least, that ctime is the last change...

Hi, temp3<- read.table(text=" ID CTIME WEIGHT HM001 1223 24.0 HM001 1224 25.2 HM001 1225 23.1 HM001 1226 NA HM001 1227 32.1 HM001 1228 32.4 HM001 1229 1323.2 HM001 1230 27.4 HM001 1231 22.4236 #changed here to test the previous solution ",sep="",header=TRUE,stringsAsFactors=FALSE) ?tempnew<- na.omit(temp3) ?grep(&quo...

On 8 September 2015 at 13:57, Kevin Korb <kmk at sanitarium.net> wrote: Hi Kevin. > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The ctime will always be newer or the same as the mtime. This is > because changing the mtime also changes the ctime as does other things > like changing the permissions. > > Rsync only pays attention to the mtime because rsync can set a > specific mtime (--times) but setting a specific ctime...

Problem: Want to be able to produce a qcow2 file with multiple ext4 File Systems. Days later want to reproduce the production of the qcow2 and have the exact same byte-for-byte file, to prove my build is reproducible. Currently the ctime attributes of the inodes will differ and thus the qcow2 files will differ. Since the file times are subsecond the trick of setting the system time and chmoding the files will not work. In https://stackoverflow.com/questions/47440618/changing-qcow2-st-ctime I mention how debugfs can be used to cha...

Dear R People: I am looking at the ctime attribute of two different files. It contains the year, month, day, time of creation and time zone. Is there a way to determine the difference between the ctimes of two files, please? I looked in the chron package and nothing seemed to work. Thanks in advance, Sincerely, Erin -- Erin Hodgess...

...ng rsync for updating a huge software library containing binaries, text files, symlinks, and so on. We've been using something homegrown which I'm not that happy with - it's a perl script that systems cp and chmod and such. The problem I'm seeing is: target computer: directories ctime-5 and ctime-5b3 are distinct directories source computer: ctime-5 is a symlink that points at ctime-5b3 When I do: /export/home/dcslib/rsync -abvx rsync://okazaki.acs.uci.edu/sun4-5 . I unfortunately get: delete_file: rmdir(packages/ctime-5.0) : File exists rsync: symlink "packages/ctim...

...12 05:35:14 2006 host: server scan config: server (abcdefg) log file: no log file generated, see system log. base database: 56 compare database: 57 [211][server][cmp][/usr/bin][mtime][Sun Aug 6 04:02:20 2006][Sat Aug 12 04:02:22 2006] [213][server][cmp][/usr/bin][ctime][Sun Aug 6 04:02:20 2006][Sat Aug 12 04:02:22 2006] [204][server][cmp][/usr/bin/afs5log][checksum][b838bb6106250fdfd95ae8a7dc7fa95b8f762df4][a4c817dd8ca12449dc1a8bdf7f972c19aa3ffd7b] [206][server][cmp][/usr/bin/afs5log][inode][22423][22422] [213][server][cmp][/usr/bin/afs5log][ctime][Thu Jun 29 21...

I am going to convert my 32-bit Debian system to a 64-bit Debian system today. But, after I move my maildir files over to the new hard drive the ctimes are going to get modified to current time and mess up my automatic purge scripts for the Deleted Items folders. Is it possible for me to either keep the existing ctimes or is it possible for me to modify the ctimes to the date headers of the emails after I move the files? Thanks, Jeff

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The ctime will always be newer or the same as the mtime. This is because changing the mtime also changes the ctime as does other things like changing the permissions. Rsync only pays attention to the mtime because rsync can set a specific mtime (--times) but setting a specific ctime is impossible as it wou...

...should be - --itemize-changes. --verbose is utterly useless without it. On 09/07/2015 11:10 PM, Andrej wrote: > On 8 September 2015 at 13:57, Kevin Korb <kmk at sanitarium.net> > wrote: Hi Kevin. > > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> The ctime will always be newer or the same as the mtime. This >> is because changing the mtime also changes the ctime as does >> other things like changing the permissions. >> >> Rsync only pays attention to the mtime because rsync can set a >> specific mtime (--times) but se...

Hello insiders is there low level support to change inode ctimes somehow? (on ext[234] it can be done using debugfs) It would be nice to make received snapshots as similar as possible to their send source. (I am not talking about uuids and such, just ls -lc output) creative ideas are welcome, Karl -- To unsubscribe from this list: send the line "unsubs...

...new options to efficiently synchronize these files. To make this report as clear as possible, I kindly remind that modification times (mtime) can be manually set by users (e.g. with touch) and rsync will preserve those during synchronization (with -a, which includes -t). By contrast, change times (ctime) are automatically updated by the OS when files are changed. rsync relies on modification times to decide whether it should skip or transfer files. There are some use cases where files are modified while preserving their original sizes and mtimes. This can happen when a fixed-size file is updated...

...;m trying to figure out what the algorithm is that causes it): ---- Inode: 209219 Type: regular Mode: 0644 Flags: 0x0 Generation: 3550218717 User: 0 Group: 0 Size: 102400 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 208 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x4165bae1 -- Thu Oct 7 17:53:37 2004 atime: 0x4165bade -- Thu Oct 7 17:53:34 2004 mtime: 0x4165bae1 -- Thu Oct 7 17:53:37 2004 BLOCKS: (0-11):453994-454005, (IND):454006, (12-13):454007-454008, (14-24):455201-455211 TOTAL: 26 Inode: 209219 Type: regular Mode: 0644 Flags: 0x0 Generati...

$ /usr/sbin/dovecot --exec-mail ext expire-tool --test Info: Trash: timestamp 1243963680 (Tue Jun 2 19:28:00 2009 ) -> 1244307774 (Tue Jun 2 19:28:00 2009 ) Both human readable timestamps are equal as ctime() returns a pointer to a static buffer. In addition there are some newline characters added by ctime(). The following patch is a try to fix this for 1.2.rc5. --- expire-tool.c.orig 2009-06-06 13:29:31.000000000 +0200 +++ expire-tool.c 2009-06-06 15:17:07.000000000 +0200 @@ -351,9 +351,13 @...

Hi, Arthur found out that ext3 is not changing the ctime on the "old_dir" (the object that is being renamed), but ext2 does. It looks to me like this is simply an omission of the following little patch from namei.c - Peter - --- fs/ext3/namei.c.orig Mon Mar 19 22:55:03 2001 +++ fs/ext3/namei.c Mon Mar 19 22:53:40 2001 @@ -985,6 +...