This is a discussion on Re: Re: "Date Created" missing on files transferred from an ext3 within the Rsync forums, part of the Networking and Network Related category; --===============1549859758== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
--===============1549859758==
Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Simo Sorce wrote: <blockquote cite="mid:%3C1209142557.3329.266.camel@localhost.l ocaldomain%3E" type="cite"> <pre wrap="">On Fri, 2008-04-25 at 18:40 +0200, Paul Slootman wrote: </pre> <blockquote type="cite"> <pre wrap="">On Fri 25 Apr 2008, Kor Kiley wrote: </pre> <blockquote type="cite"> <pre wrap="">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 </pre> </blockquote> <pre wrap="">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... </pre> </blockquote> </blockquote> I am aware of the ext3 and NTFS timestamp differences. If a create date didn't show up in any of the files transferred to the windows server, I might assume that this is the way that unix/windows date stamp differences were intended to be handled. However, the fact that around 50% of files did get a create date, and that the date reflects the time the file was transferred, makes me think that this is what was supposed to happen. The fact that using cp to copy files from the linux box to the windows box always leaves a file with a create date, reinforces my assumption.<br> <blockquote cite="mid:%3C1209142557.3329.266.camel@localhost.l ocaldomain%3E" type="cite"> <pre wrap=""><!----> 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. </pre> <blockquote type="cite"> <pre wrap="">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? </pre> <blockquote type="cite"> <pre wrap="">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 </pre> </blockquote> <pre wrap="">"Backup software" should look at the modification time, not at the "creation date" or ctime. Is this "backup software" something different than rsync? </pre> </blockquote> <pre wrap=""><!----> 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. </pre> </blockquote> </body> </html> --===============1549859758== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- 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 --===============1549859758==-- |