search for: ctimes

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 handled. This patchset first

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

I am using outgoing call files. I typically see the "ooh something changed / timeout" on a regular bases every second to be exact. Then it stops until some other call event happens. So I "mv" my call file to the outgoing spool directory, I am listening to that message, another call file is "mv"'ed into the directory and something happens to the timeout that its

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

(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 time (not the creation time).

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("\\d{4}",temp3$WEIGHT) #[1] 7 9 #not correct

...pected to match, therefore > it is useless to rsync. If this is the case I don't understand the behaviour I'm seeing here. The files mtime haven't changed, the time-stamps of the copies on the backup server and the time-stamp on the iSCSI mount are the same (the mtime, that is; the ctimes differ, obviously, as all files have the time-stamp of the mount-event). Do you have an explanation? > Rsync should be using the delta transfer algorithm (unless > - --whole-file) so it really should just be determining what is > different about the file then transferring those differen...

...tes 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 change the ctimes. Two possible usages come to mind: 1. A global flag that would indicate the ctime that should be used for all file operations, e.g. a fake system clock. 2. A new command to specifically change the ctime, like debugfs's set_inode_field. Thanks Marc

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 Associate Professor Department of Computer and Mathematical Sciences University of Houston - Downtown mailto: erinm.hodgess at gmail.com

I'm trying to switch to using 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:

Hi list, I'm a bit worried here. On a server, Centos 4.3 fully-patched SELinux activated, Osiris (a decentralized scanner for files changes on distant servers) signaled me several changes on files who were not (at first sight) affected by a recent update (the list is below). Is there a logic explanation for those changes to happen ? The "rpm -Va" command does not output md5sum

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 would violate the basic *nix security model.

...refore it is useless to rsync. > > If this is the case I don't understand the behaviour I'm seeing > here. The files mtime haven't changed, the time-stamps of the > copies on the backup server and the time-stamp on the iSCSI mount > are the same (the mtime, that is; the ctimes differ, obviously, as > all files have the time-stamp of the mount-event). > > Do you have an explanation? > > >> Rsync should be using the delta transfer algorithm (unless - >> --whole-file) so it really should just be determining what is >> different about the...

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 "unsubsc...

...intensive and will check all files --ignore-times option will force a (re)synchronization of all files To solve this issue, we could check change times. Considering that rsync will not be able to control change times on the receiving side, we must be careful. If we suppose that rsync used ctimes (and not mtimes) to compare these files, it would first find that srcfile is newer, and then on subsequent rsync passes, it would find that destfile is newer. Therefore we can't transfer files if [srcfile's ctime != destfile's ctime]. However we can use a combination of mtime and ctime...

Greetings all- I am conducting security testing on a device that uses Linux 2.4 with ext3. I am testing secure overwrite of remnant data in temporary files, but have run into a real good stumpper in the way Ext allocates data blocks. I've got 10 yrs of *NIX behind me, several with Linux, and this has really got me perplexed as I can't find any documentation explaining the subject

$ /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

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 +985,13 @@ new_dir->i_version =