OT: rsync on Mac OSX
chris at chrismaness.com
Fri Jul 12 18:25:52 UTC 2013
On Fri, Jul 12, 2013 at 11:12 AM, Paul Kraus <paul at kraus-haus.org> wrote:
> Dropping the list …
> On Jul 12, 2013, at 1:49 PM, Chris Maness <chris at chrismaness.com> wrote:
> > Checksums are the same. All other files still work however the HUGE
> > rendered Final Cut Pro output, so I guess it is something in .DS_Store.
> > Last time I just gave up and recopied everything by a simple cut and
> > and that solved the problem. I made a small change on the project today,
> > and I don't want to have to copy the WHOLE thing again just for a small
> > delta. I already synced the directories, but the new rendered files are
> > still un-openable in any application even though the checksums match.
> > Really weird. However, the project will still open and work on FCP.
> > the 12Gb rendered movie files will not play on anything even FCP. If I
> > delete .DS_Store will the system regenerate it with the appropriate file
> > associations?
> The .DS_Store files are created by the Finder when you view a directory.
> Are both source and destination on Mac HFS+ volumes ? If so, then you are
> probably missing the resource forks.
> Back in the very old days of Mac OS (way before 10.x), Mac OS files had
> two parts, the data part that contained the, well, data, and the resource
> fork that contained the meta-data that Mac OS used to associate a file with
> an application. HFS+ volumes on Mac OS X still include the resource forks,
> but "foreign" filesystems (NFS, UFS, FAT, etc.) do not. The work around
> that Apple came up with is to create .DS_Store and ._<foo> files to store
> this metadata on non HFS+ volumes.
> You could try using ditto instead of rsync. ditto is a BSD derived copy
> utility similar to rysnc, but I know that the Mac OS X version understands
> resource forks and copies them as necessary. ditto may not be able to just
> copy changed blocks within a file, so you may still have to recopy the
> entire file.
> But…. I am also a little puzzled because applications on Mac OS X do not
> NEED the resource fork to open a file, just to know which application to
> use (and what options to hand it) to open a given file. A complete video
> file, even without resource forks, should be able to be opened if you
> explicitly telly he application to File -> Open …. With the checksums
> matching it is even odder. I expect that the large sizes (over 4 GB) are a
> contributing factor.
> Good luck and let me know what you find.
> Paul Kraus
> Deputy Technical Director, LoneStarCon 3
> Sound Coordinator, Schenectady Light Opera Company
Thank you for the detailed description of what resource forks are. One
more clue in this mystery is that appending .mov extension to it fixes the
problem. I have never ran into this before, and I have even used rsync to
back up movie projects before. It is not a big deal, but I always try to
take the time to understand why things behave the way they do. I also
suspect it has something to do with file size since all of the smaller
files do not have this issue.
More information about the freebsd-questions