similar to: mtime vs ctime

Displaying 20 results from an estimated 7000 matches similar to: "mtime vs ctime"

2015 Sep 08
0
mtime vs ctime
-----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.
2015 Sep 08
2
mtime vs ctime
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
2008 Aug 24
1
mtime, atime, ctime
Hello I am making backup of a Plesk Debian server to /backup using Rsync. My questioin is how can I preserve the ctime, mtime, and atime of original files? Thanks
2015 Sep 08
0
mtime vs ctime
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would need to see both your existing rsync command line and the output of --itemize-changes when such an occurrence happens before I can really understand what is happening. In the end, if you have any output at all the bare minimum should be - --itemize-changes. --verbose is utterly useless without it. On 09/07/2015 11:10 PM, Andrej wrote: >
2019 Jan 02
6
[Bug 13735] New: Synchronize files when the sending side has newer change times while modification times and sizes are identical on both sides
https://bugzilla.samba.org/show_bug.cgi?id=13735 Bug ID: 13735 Summary: Synchronize files when the sending side has newer change times while modification times and sizes are identical on both sides Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW
2013 Oct 25
2
btrfs send/receive do not keep inode ctimes
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 "unsubscribe linux-btrfs" in the body
2014 Dec 03
1
Aw: Re: Re: encrypted rsyncd - why was it never implemented?
> The benefit of rsync over ssh secured by rrsync is that it is more > like what rsync users are already used to. i don`t like rsync over ssh in an environemt with users you can?t trust. from a security perspective, i think such setup is broken by design. it`s a little bit like giving a foreigner the key to your front door and then hope that the door in the corridor to your room will be
2014 Dec 03
1
Aw: Re: encrypted rsyncd - why was it never implemented?
On 12/03/2014 01:37:58 PM, Kevin Korb wrote: > As far as a backup provider goes I wouldn't expect them to use rsync > over SSL unless that were built into rsync in the future (and has > been > around long enough that most users would have it). > > I would expect them to either use rsync over ssh secured by rrsync or > rsyncd over ssh with them managing the rsyncd.conf
2008 Dec 19
1
Does file.info man page describe ctime corrrectly?
(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).
2004 Oct 26
1
[Fwd: question for file attributes (atime, ctime)]
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
2015 Oct 17
2
Order in which UIDs are assigned..
Hi, I just want some clarification on how Dovecot's IMAP assigns UIDs when it picks files from the "new" directory of a Maildir. What I am observing is that only ctime has a role to play in it. For example if there are two files in "new", a.msg & z.msg. Even when a.msg has lower mtime than z.msg and "a" comes before "z" alphabetically, dovecot
2009 Oct 09
1
How to get "last status change", ctime on Windows?
Hi, file.info is producing data.frame with ctime variable. Help file says that on Unix this is 'last status change' and on Windows 'creation time'. Is there a way to get 'last status change' on Windows using some R function? Thanks, Johannes
2005 Jul 13
0
Blank ctime or mtime causes on files in profile
I have Samba 3.0.9 running on SuSE 9.2, 2.6.5-7.111-smp kernel. SAMBA is a PDC using OpenLDAP as a passdb backend.??Workstations?are?combination?w2k SP3, SP4, and Windows XP SP1. The problem I have is with profile synchronization. If?a?user?obtains?a?file that has a blank modified time, Windows substitutes Jan 13, 2038 for the
2017 Nov 23
1
RFE: ctime byte-for-byte reproducible qcow2 ext2/3/4 FS
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
2015 May 18
1
mtime not updating on remote directory
Hello, I'm using rsync as part of a centralised config management for several servers. I'm trying to monitor the mtime of a particular directory and confirm that the remote copies are approximately as new as the the local master. However, mtime on that directory is not being synced. Here's my rsync command: cd $confdir && rsync -avpzR --checksum -I -e "ssh"
2014 Sep 02
1
[PATCH] rrsync: Add several long options used by BackupPC
rrsync used to throw the error /usr/local/bin/rrsync: invalid rsync-command syntax or options when run under BackupPC 3.2.1, with this patch full and incremental backups work. --- support/rrsync | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/support/rrsync b/support/rrsync index 6f83f9d..c231ea3 100644 --- a/support/rrsync +++ b/support/rrsync @@ -60,6 +60,7 @@ our
2014 Mar 11
3
Caching {filePath,mtime64,checksum} values to speed up execution-time
Folks: When using rsync to copy huge amounts of data I've found that a significant amount of time is spent computing the checksums. Sometimes hours, ... sometimes days - it depends on the total amount of data checked! And after that sometimes it's only a few files that need to be updated. I've pulled the latest git (rsync-3.1.1pre1) and didn't see anything to address this (or I
2004 Oct 08
2
Ext 2/3 overwriting remnant data & use of data blocks - security
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
2003 Aug 11
8
Samba vs. Windows : significant difference in timestamp handling ?
Hi there, i still have a weird problem with Powerpoint an Excel files stored on a Samba share. Only read on if you -use a samba share as MULTI-user file repository (no force_user etc.) -where multiple, different users share files in common directories -the modification time of a file is of any relevance to you. (seems like lots of folks don?t bother access rights or keep their information
2007 Jun 14
2
"Last changed" timestamp is ignored?
Rsync's "does this file need to be updated" check can conclude "this file does not need updating" even though the "last changed" timestamp differs. This happens when the size and modify timestamp are equal. Why doesn't rsync consider the "last changed" timestamp in the same respect as the modify timestamp? Doesn't changed mean, er, changed?