similar to: File changed as we read it.....

Hello all. Our system consists of two linux machines, each running Red Hat 7.1 (kernel 2.4.9-34), using SMB to mount multiple shares hosted by a Windows 2000 Advance Server. smbclient from Samba 2.2.5 is used to do the actual mounting. Over the weekend, a number of files on these SMBFS shares were created with incorrect timestamps (modification times). In some cases, the timestamps were off by

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

Hi, we had the same problems last year and we use NTFS. Luckely we switched to Linux this year. Kind regards, Bart Coninckx Network Administrator CNE, ASE ************************************* Sita ICT Services Lilsedijk 19 B-2340 Beerse Belgium e-mail: bart.coninckx@sita.be Tel: + 32 (0) 14 62 28 22 Fax: + 32 (0) 14 62 41 47 *************************************

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

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

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

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

Hello, We have a 3-node cluster setup with ocfs2. Since friday one of the nodes went down and would not become clustermember after a reboot because it was unable to write to the ocfs2 filesystem. Message: no space left on device. There is plenty of diskspace though. No problem whatsoever to create a file / directory on the filesystem using one of the other nodes. Today one of the remaining

On 6/30/07, Wayne Davison <wayned@samba.org> committed: > Added Files: > checksum-xattr.diff > Log Message: > A simple patch that lets rsync use cached checksum values stored in > each file's extended attributes. A perl script is provided to create > and update the values. Wayne, You should be aware of two drawbacks of caching checksums in xattrs: First,

I'm trying to clone a volume in a storage pool and I'm following the steps described here: http://libvirt.org/docs/libvirt-appdev-guide-python/en-US/html/libvirt_application_development_guide_using_python-Storage_Pools-Cloning.html My code looks like: destXML = """ <volume>

Carlos A. P. Cunha via samba wrote: > For me, is "magic line" > > find $DEST -depth -mtime +$DAYS -print -delete ---- I'm guessing you probably want 'ctime' there. If you use mtime, then it will be deleted "ndays" after the last modification date on the file -- NOT the time the file was moved into the recycle bin. If you use ctime - that

Hello, I have dovecot running with MailDir as a backend to store email and I would like to remove mail that is older that 30 days. I can do this by running 'find' on the MailDir but will this cause any issues with dovecot? Thanks, Matt. -- Matt Richards -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature

I have a large mail backup folder backup at backup.invalid; I'm cleaning up daily like this: infimum=`date -d "-4 day" +"%Y-%m-%d"` doveadm expunge -u backup at backup.invalid mailbox INBOX SAVEDBEFORE $infimum doveadm purge -u backup at backup.invalid yet I see this: # find attachments/ -type f -ctime +5 | wc -l 7522 # find attachments/ -type f | wc -l 127579 # find

Dear all, Does anyone aware of any utility to copy files which are created or modify form a specific date ?. Thanks Rajeev R. Veedu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20080609/ae761b2c/attachment-0002.html>

I am trying to find out how to tell if a given file is 30 days or older. How is that type of thing done in shell scripts. Thanks, Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20050915/e412e896/attachment.html>

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

On Fri, Feb 19, 2016 at 12:12 PM, Martin Kletzander <mkletzan@redhat.com> wrote: > On Fri, Feb 19, 2016 at 11:12:32AM +0000, Andrei Perietanu wrote: > >> I'm trying to clone a volume in a storage pool and I'm following the steps >> described here: >> >>

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

Hi, Recently I noticed file.copy() would discard the file mode information. Is this the expected behaviour or a bug for file.copy()? > file.create('testfile') [1] TRUE > file.info('testfile') size isdir mode mtime ctime testfile 0 FALSE 644 2011-03-05 17:06:39 2011-03-05 17:06:39 atime uid gid uname grname

Hi, Recently I noticed file.copy() would discard the file mode information. Is this the expected behaviour or a bug for file.copy()? > file.create('testfile') [1] TRUE > file.info('testfile') size isdir mode mtime ctime testfile 0 FALSE 644 2011-03-05 17:06:39 2011-03-05 17:06:39 atime uid gid uname grname