import sessions copied from external disks problem

lewisl

• February 09, 2016 23:11

I reported the problem with importing catalogs copied from an external disk.

It turns out there is a version of the problem with sessions.

If you copy a complete session folder from an external disk to a local disk and use the "import session" command, the session will not import. It will try. The collection will be built for the session. But, there will be no images. This is especially odd because I can open the local session directly in C1 and see that its folders are all relative to session (use show info in the library folders section).

So, what gives? It turns out that even though the folders of the session are relative paths (or links as people at C1 seem to say), the volume name for the session is in the session metadata. You can see this if you try to add the local folders and then synchronize them. When the synchronize brings up the import images dialog and if you explicitly set the location for import to (choosing the local drive) the volume that shows up is the volume name of the external drive. If you delete the volume name, the synchronize--just syntactic sugar for import images--command works.

But, directly using the import session command will not work.

The work around for this is to use import images from the local folders of the copied session, using "current location" as the import to location. Turns out this works perfectly. So this is the the workaround.

What a shame that these nice new commands have some many cases that aren't supported.

Let me report for Capture One dev's that there is also one very important fact about the configuration that may explain why others are not reporting these problems:

I am working on os x el capitan. The external drive is formatted exfat, which is a Microsoft developed format that is meant for large capacity external drives that are meant to work across platform. It is possible that on os x, Capture One works with the exfat formatted drives but that the way file system metadata gets captured is a big mangled when the sessions (and catalogs) are copied to an HFS drive. The mix of file system metadata *might* be something to look at.

This is a significant problem because most external drives sold as "cross platform" are formatted as either FAT32 or exfat. Only the Mac specific drives (say from, LaCie) are likely to be formatted as HFS. I am not going to test this hypothesis. We'll leave that for C1 testing/dev to try. Probably someone can just tell by trying what I've tried and looking at the code.

0

• 

  Peter Sidell

  • February 12, 2016 03:27

  Why don't you use disk utility to reformat your drives before beginning to use them.
  
  I don't think that solves your problem with regard to the session or catalog knowing where to look for files, but it does remove that variable.
  
  Also rather than importing a session you can point directly to the folder with the images from within catalog and review and adjust them without the need for a formal import
  I am not sure yet, but i believe that allows you to clone a disk and have the adjustments and ratings travel.
  I don't really see the value in using an import when working with a session. It duplicates the images. I suppose it is useful if that is the point in your workflow when you copy from the memory card to the hard disk. Otherwise point directly at the folder with the images.

  0
• 

  SFA

  • February 13, 2016 04:13

  [quote="lewisl" wrote:
  I reported the problem with importing catalogs copied from an external disk.
  
  It turns out there is a version of the problem with sessions.
  
  If you copy a complete session folder from an external disk to a local disk and use the "import session" command, the session will not import. It will try. The collection will be built for the session. But, there will be no images. This is especially odd because I can open the local session directly in C1 and see that its folders are all relative to session (use show info in the library folders section).
  
  So, what gives? It turns out that even though the folders of the session are relative paths (or links as people at C1 seem to say), the volume name for the session is in the session metadata. You can see this if you try to add the local folders and then synchronize them. When the synchronize brings up the import images dialog and if you explicitly set the location for import to (choosing the local drive) the volume that shows up is the volume name of the external drive. If you delete the volume name, the synchronize--just syntactic sugar for import images--command works.
  
  But, directly using the import session command will not work.
  
  The work around for this is to use import images from the local folders of the copied session, using "current location" as the import to location. Turns out this works perfectly. So this is the the workaround.
  
  What a shame that these nice new commands have some many cases that aren't supported.
  
  Let me report for Capture One dev's that there is also one very important fact about the configuration that may explain why others are not reporting these problems:
  
  I am working on os x el capitan. The external drive is formatted exfat, which is a Microsoft developed format that is meant for large capacity external drives that are meant to work across platform. It is possible that on os x, Capture One works with the exfat formatted drives but that the way file system metadata gets captured is a big mangled when the sessions (and catalogs) are copied to an HFS drive. The mix of file system metadata *might* be something to look at.
  
  This is a significant problem because most external drives sold as "cross platform" are formatted as either FAT32 or exfat. Only the Mac specific drives (say from, LaCie) are likely to be formatted as HFS. I am not going to test this hypothesis. We'll leave that for C1 testing/dev to try. Probably someone can just tell by trying what I've tried and looking at the code.

  
  
  Have you created a Support Case?

  0

Post is closed for comments.