Date Created missing on files transferred from an ext3 file system to an NTFS file system
I'm using rsync 2.6.9 to transfer tiff files from a linux RHEL 5 server to an NFSv3 directory exported by a NAS running Windows Storage Server 2003 R2 sp2. The NAS is running Microsoft Services for NFS. The rsync command I'm using is: rsync -auz --remove-source-files /m2/archives /nfs-destination The problem I'm having is that ~50% of the files that are moved are missing a creation date. The main problem with this is that the backup software always thinks that they are new versions and always backs them up during an incremental backup. I also haven't found a good way of supplying the creation date on files that have already been moved the the NAS. If anyone can provide insight into this problem, I will be grateful. Kor -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Date Created missing on files transferred from an ext3 file system to an NTFS file system
On Fri 25 Apr 2008, Kor Kiley wrote: The rsync command I'm using is: rsync -auz --remove-source-files /m2/archives /nfs-destination The problem I'm having is that ~50% of the files that are moved are missing a creation date. The main problem with this is that the backup There is no such thing as a creation date in unix/linux. Commonly people misinterpret the ctime field as having something to do with creation, but actually the C stands for inode change. Hence the ctime will be updated if you change the owner of a file, or make a hard link to the file; anything that changes the information in the inode. Of course, I don't know what your combination of NFS over an NTFS disk does with such unix concepts... When data is copied with rsync, the ctime field should contain the current timestamp. Not having any ctime would be surprising. It would help if you explained exactly why you think the creation date is missing, what tools have you used to determine this and what exactly do they show? software always thinks that they are new versions and always backs them up during an incremental backup. I also haven't found a good way of Backup software should look at the modification time, not at the creation date or ctime. Is this backup software something different than rsync? Paul Slootman -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Date Created missing on files transferred from an ext3 file system to an NTFS file system
On Fri, 2008-04-25 at 18:40 +0200, Paul Slootman wrote: On Fri 25 Apr 2008, Kor Kiley wrote: The rsync command I'm using is: rsync -auz --remove-source-files /m2/archives /nfs-destination The problem I'm having is that ~50% of the files that are moved are missing a creation date. The main problem with this is that the backup There is no such thing as a creation date in unix/linux. Commonly people misinterpret the ctime field as having something to do with creation, but actually the C stands for inode change. Hence the ctime will be updated if you change the owner of a file, or make a hard link to the file; anything that changes the information in the inode. Of course, I don't know what your combination of NFS over an NTFS disk does with such unix concepts... FYI: While ext3 does not have a creation time field, NTFS does. What the w2k3 NFS server does is hard to say given no sources are available (Afaik). In any case rsync is probably not to blame as the NFS layer will probably mask any chance for rsync to deal with native NTFS creation time even if it were willing to. When data is copied with rsync, the ctime field should contain the current timestamp. Not having any ctime would be surprising. It would help if you explained exactly why you think the creation date is missing, what tools have you used to determine this and what exactly do they show? software always thinks that they are new versions and always backs them up during an incremental backup. I also haven't found a good way of Backup software should look at the modification time, not at the creation date or ctime. Is this backup software something different than rsync? Windows has a real creation time in the metadata, so it is certainly correct for native backup tools to look into that date too. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 5418] New: rsync error: error allocating core memory buffers (code 22)
https://bugzilla.samba.org/show_bug.cgi?id=5418 Summary: rsync error: error allocating core memory buffers (code 22) Product: rsync Version: 3.0.2 Platform: Other OS/Version: AIX Status: NEW Severity: major Priority: P3 Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] I am using rsync 3.0.2 (on both ends) to copy a source tree from Mac OS (Intel) to AIX (Power 5). My command is rsync --rsync-path=/work/default/eschnett/rsync-3.0.2/bin/rsync --rsh ssh --archive --hard-links --sparse --verbose --progress --partial --stats --compress --exclude _darcs --exclude CVS --exclude doxygen --exclude .#* --exclude .DS_Store --exclude .git --exclude .svn --exclude *~ --delete --delete-excluded CONTRIBUTORS COPYRIGHT Makefile arrangements src lib .gitignore AEIArrangements AEIPhysics bbhfactory bin cactus.config carpet carpet-stable carpet-stable-2 carpet-stable-3 kranc parfiles [EMAIL PROTECTED]:/work/default/eschnett/Calpha After checking about 8000 files, I receive the error sending incremental file list rsync: connection unexpectedly closed (794 bytes received so far) [sender] rsync error: error allocating core memory buffers (code 22) at io.c(635) [sender=3.0.2] With two additional --verbose options, the last screen output is recv_generator(arrangements/AEIDevelopment/BbhIData/src/BbhCollabInitialData/t7600/Nid_gyy_SphereC1.dump,8043) arrangements/AEIDevelopment/BbhIData/src/BbhCollabInitialData/t7600/Nid_gyy_SphereC1.dump is uptodate send_files(8043, arrangements/AEIDevelopment/BbhIData/src/BbhCollabInitialData/t7600/Nid_gyy_SphereC1.dump) recv_generator(arrangements/AEIDevelopment/BbhIData/src/BbhCollabInitialData/t7600/Nid_gyy_SphereC10.dump,8044) arrangements/AEIDevelopment/BbhIData/src/BbhCollabInitialData/t7600/Nid_gyy_SphereC10.dump is uptodate send_files(8044, arrangements/AEIDevelopment/BbhIData/src/BbhCollabInitialData/t7600/Nid_gyy_SphereC10.dump) Here the transmission hangs. When I abort with ctrl-C, I receive ^CKilled by signal 2. rsync error: unexplained error (code 255) at rsync.c(541) [sender=3.0.2] _exit_cleanup(code=20, file=rsync.c, line=541): about to call exit(255) This is a show-stopper for using rsync 3.0.1 and 3.0.2 on AIX. I have no such problems on other platforms which use Linux operating systems and Intel processors. My current work-around is to fall back to 2.6.2. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 5404] rsync --dry-run should show where files will go
https://bugzilla.samba.org/show_bug.cgi?id=5404 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #2 from [EMAIL PROTECTED] 2008-04-25 19:10 CST --- I hope reopening the bug doesn't violate etiquette. But -i gives me little satisfaction. As the man page says, the output is utterly cryptic, and amongst the zillions of options, -i is very obscure. Why not have -n print something like this, kind of like /bin/cp -v, for each file: /source/path/file - dest-host:/dest/path/file -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
