Announcement

Collapse
No announcement yet.

Snapshot fails on some network files, while sync works

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Snapshot fails on some network files, while sync works

    Using BC Pro 3.3.4.

    We are doing scripted backups on a XP machine, off a server share to a local drive.

    Sync-ing from the network share to the local drive - everything works fine, all files are compared and synced successfully. Using windows explorer's copy/paste works as expected, too. No problems with permissions, or files being locked.

    Taking a snapshot, and then syncing it to the local drive (same session and same settings) - the operation fails on some files with the following error:
    Unable to copy xxx\xxxx.bcss\xxx\xxx: Container does not support requested file operation.
    Same error comes out using GUI mode. The failed files have different extensions, some are even plain log files. The failed targets are created with 0 size. Running it this repeatedly does not help - it fails on exactly the same files.

    Here's a snippet from the BC script:
    Code:
    filter "-~$*.*;-thumbs.db;-*.tmp"
    snapshot path:"\\SERVER\SYSTEM" output:"%temp%\snap-sys.bcss"
    filter "*.*"
    load create:right "%temp%\snap-sys.bcss" "D:\SYSTEM\"
    SYNC create-empty mirror:lt->rt
    What could be the problem?

    Thanks!

  • #2
    Hello,

    A snapshot file is a virtual representation of the folder and file structure. It contains things like the file name, timestamp/size information, etc, but does not actually contain a file or any data. You cannot sync from a snapshot to another location (or into a snapshot, either). They are used for situations where you would like to compare "remotely" but do not have direct access to the remote location, or if you wish to take a snapshot in time, and compare against itself at a later date. Here's an example:
    http://www.scootersoftware.com/suppo...=kb_sneakernet
    Aaron P Scooter Software

    Comment


    • #3
      Hi

      Thanks for the clarification. The help was not clear enough. I thought "readonly" means you can read from it, and not only the metadata for comparison, but also the files themselves.

      A snapshot contains references that CAN be used to point to folders/files on the actual filesystem. Why not make it possible then to take action (copy, delete) on the filesystem directly, using those references? They are there, anyway, right?

      Thanks.

      Comment


      • #4
        The way snapshots are designed, the files it is referencing are not necessarily present (either entirely or just an individual file might be missing). We have a reference to the location the snapshot was taken with, for easy comparing "against itself", but the contents are not guaranteed even if this location still exists.

        What is your current workflow? If you expect to have access to the original location to perform a copy using the reference, couldn't you open the original location instead of the snapshot? You can mark either side of the comparison as Read-Only if you are trying to protect it using the Session Settings.
        Aaron P Scooter Software

        Comment


        • #5
          Regarding the "snapshot containing referencing that are not necessarily present", I would argue that you have the same situation when you load and expand a comparison in memory, then try to sync it. If the comparison takes long enough, and the source filesystem changes frequently, then when you reach the sync phase, you may have quite a number of files and folders that don't exist anymore on the source side. Fortunately the sync is not caught by surprise and will not fail.
          I still consider that enabling snapshots to be used in sync operations is a great benefit.

          Regarding my workflow, I'm trying to accomplish the following:
          1. Sync (mirror) 2 locations (say, from A to B)
          2. Both locations have some folders (say, X and Y) that need to be excluded from sync, so that they are removed automatically (part of the mirror operation) from side B
          3. I apply a filter before load/sync (say, filter "-X;-Y")
          4. The filter applies to both sides (for some reason), X and Y get hidden, and not removed from side B
          5. To come around this, I take a filtered snapshot of side A (filter "-X;-Y")
          6. Then run a sync to get the visible files across from A to B
          7. Remove the filter, and run a comparison of the snapshot with side B (filter "*.*")
          8. Then delete orphans from side B
          9. This doesn't work well for some reason, as I'm running into problems deleting orphan folders (see the separate thread I created).

          Hope this is clear. Any suggestions?

          Comment


          • #6
            Hello,

            Single sided filters is something we are looking to add in a future version of Beyond Compare, but are not currently supported. The first half of your steps look like a scenario to try and use snapshots as a means to apply a filter to only one side, but the second half then tries to delete those items previously filtered out?

            For this workflow, what do you mean by "X and Y that need to excluded from the sync", but then are "removed from both sides"? Is your goal to delete content X and Y on side B during a sync? And both X and Y present in both A and B, or are you running into some scenario where A\X is on one side, and B\X and B\Y are on the other? If you have a specific target for deletion, you can set the filter to show only those items, then select all files on that side and delete them outright, as a separate step from the Sync.
            Aaron P Scooter Software

            Comment

            Working...
            X