Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16
  1. #11
    Join Date
    Mar 2015
    Posts
    7

    Default

    Dear Aaron,
    the fact that Open With doesn't populate %f2 or at least %p2 with a blank selection on the right side is yet another issue, which I have seen being discussed elsewhere in the forum. My issue is a different one:

    I did exactly what you say: My "Open With" command lines is
    Code:
    bcompare.exe "%f1" "%f2"
    and also the associated description is bcompare.exe "%f1" "%f2" which you will find in the Open-With submenu in my first sceenshot, highlighted in light blue. Also visible in both of my screenshots, highlighted in light green, are the selections on both sides, no blank selections. However, I still get the behavior of BC3 just using %f1 twice, once for the left file and once for the right file, all while keeping %f2 blank, as soon as Multiple instances is selected.

    Re-testing this, I'm having trouble getting the BC2 behavior to reproduce (it's mostly behaving the same as BC3/4), but I remember it triggering in specific scenarios.
    I would be very happy to see a specific scenario where BC3 actually does what you explained i.e. opening multiple tabs of file pairs. For me this works for a single tab only, and only if Multiple instances are turned off.

    Could you go into a bit more detail on why our Move command or Move to Folder command does not work in this scenario for you? Is the RoboCopy Move handling the SD Card in a better way?
    The main reason is that BC3 doesn't allow to replicate the subfolder structure when Ignore folder structure is selected. This is indicated by the "red Ø over a folder" icon just to the left of the ≈ icon in the toolbar of my second screenshot. I am adding the complication in my scenario that I do not want to move or copy the files on the right. I only want to use their subfolder location and replicate it on the left. So I am moving the files from the left to the left, using the subfolder structure on the right. It would be great if BC could do this directly but alas...

    One additional advantage of using RoboCopy is that it can copy also file and folder creation dates, an often demanded feature only recently added to BC4 for files, but not yet for folders. After the files are sorted into the correct structure on the SD Card, I call RoboCopy with Open With to fix the time stamps on the newly created manually\sorted\ folder structure. Here, I have no trouble, because I can do this by calling RoboCopy once for the whole subfolder structure from its top folder down and I can do it without Multiple instances.

    • The creation dates of pictures typically indicate, when the picture has been taken (EXIF date taken).
    • The modification date shows when the picture was last edited (e.g. cropped, color corrected, etc.)
    • The creation date of the event folder indicates, when the pictures where first manually sorted into this event.
    • The modification date shows when data about this event has last been updated inside this folder.

    With the correct RoboCopy parameters, all the above dates stay preserved. Many other move/copy routines including most of the ones inside BC, mess them up. The nice thing about RoboCopy is, that it can repair a lot of the timestamp mess left after most BC operations and it does it even very fast.

    If it were possible to generate a filename filter to limit the view to the specific selection you needed for a specific move, this might help then allow for an easier "Select All Files" -> Move/Move To Folder.
    My real use case has hundreds of different folders to move to, not just two as in my example, which I simplified in order to fit it into a single screenshot. They can all be easily selected by switching off the orphan display, then marking them all in a single click and shift-click operation. Subsequently, I re-displayed the orphans, in order to indicate in the screenshot that I only want to move the files already on the SD Card, not the ones which might have been added from different sources into the \manually\sorted folder structure on the right side.

    The ideal solution for me would be to select all the files inside the DCIM\100ANDRO folder that have an equivalent on the right side and then chose the BC Move-to-Folder command with the Folder Structure option selection "replicate relative folder structure from the other side" ... if such an option existed

    Hopefully, this post sheds more light on my scenario.

  2. #12
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    11,375

    Default

    Ah, sorry, I accidentally tested with my BC4 install instead of BC3 when double checking %f1 %f2 with Multiple Instances enabled. Double checking for BC3, this wasn't available and something we fixed for BC4.

    I'd suggest installing the trial of BC4 (a separate install of BC3 on Windows) and test out your workflow with this Open With.
    http://www.scootersoftware.com/download.php
    Does this help with your custom Open With and with the Creation Dates for Files (you'd still need Robocopy for folders, as you point out)?

    And I see about your scenario. It's almost like a "Touch Folder Structure" command.
    Aaron P Scooter Software

  3. #13
    Join Date
    Mar 2015
    Posts
    7

    Default

    Aaron,
    yes, my "Touch Folder Structure" command works almost like the BC internal Touch function when selecting "copy timestamps from other side". However, it copies all available time stamps, modification AND creation dates and can also be extended to copy permissions for files AND folders, if necessary.

    I use it very frequently, almost after every bigger sync operation with BC, to clean up the times stamps. It would be my dream if BC would just do this by itself. Frankly, I don't think it would be that much work to implement...

    And while you're at it, you could add a feature that I haven't seen anywhere else on the market, that is to propagate the OLDEST CREATION DATE. After doing lots copying, editing and syncing, the creation date gets frequently messed up because it it ignored by many programmers, who have never dealt with heaps of historical data. Like in archaeology, a correct creation date is always very helpful to weed out the rubbish from the useful. Isn't that what BC is all about? At least that's what I am using it for on a daily basis. BTW, Thank you for creating this almost irreplaceable jewel.

    I will try BC4. is your offer for the BC2 key also valid for 4? After all, my BC3 help file already promises me that I can do it.

  4. #14
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    11,375

    Default

    Hello,

    If you write in to support@scootersoftware.com (with a link to this forum thread for our reference), we can provide key for a previous major version if you need it. Since you already own BC3, you are welcome to try BC2. However, as you mention earlier, BC2 does not allow you to Ignore Folder Structure, so it may not meet your needs. On Windows, you can have installs of BC2, BC3, and BC4 at the same time; either as registered or in trial mode for each. The only conflict is the Windows right-click shell extension. I'd recommend disabling it for all versions but one to avoid any overlap or confusion (and you can always disable/enable different versions in each's Tools menu -> Options dialog).

    Part of the issue is it is not just developers who ignore Creation date, but Windows. A regular Windows Copy preserves the Modified date, but it is convention to update the Creation date of the new copy. It's on our wishlist to expand our functions for preserving and touching different timestamps, but there's always a good chance another program or the OS would update them.
    Aaron P Scooter Software

  5. #15
    Join Date
    Mar 2015
    Posts
    7

    Default

    Aaron,
    your are right, that even then developers of operating systems ignore creation dates or do not deal with them properly. If they were also librarians, historians, forensicists or archaeologists, they would.

    That is why I suggested that BC does it better.

    If BC regularly synchronizes between several copies of the same folder structure, always the older creation date is the one that is closer to reality (assuming correct dates in all involved systems and no corrupt or missing dates that sometimes come out as 1-1-1970 because this is t=0 in Unix, or some other specific time way back in the past or ahead in the future). So by propagating always the oldest creation date, BC would eventually also copy the original creation date from that location, a file was really originally created in. That original "oldest" date will then eventually propagate to all synchronized copies.

    Here it might actually make sense to differentiate between files and folders. If the creation dates of folders behave like they currently do with the Windows file explorer, they show, when the folder was created in this specific location. The effect is that a newer folder creation date than the creation dates of files inside that folder indicate that those files had originally been created elsewhere, which is again a very useful piece of information when synchronizing data.

    However, not propagating the oldest creation date for folders should be optional depending on how folder dates are being interpreted by the user.

    It even makes sense to propagate the oldest modification date after a positive binary or CRC comparison. The "newer" file has probably been "up"-dated after a ftp or email transfer.

    It all depends, whether one is interested in the creation and modification dates of the actual content of a file or only in the reference/pointer to it inside the folder/directory. It seems that most developers are only interested in the latter.

    This is now really going off topic in respect to the title of this thread. So I suggest to continue the discussion somewhere else like for example in the thread "Created time stamp".

  6. #16
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    11,375

    Default

    Thanks for the feedback. The issue I bring up is that, even if BC4 monitors and behaves like this, it is likely that (at some point) something else (including the OS itself) could modify some of your data. Enhancing our tools to compare and set dates would certainly be useful and help propagate this workflow, but just something to be mindful of that Windows does not treat Creation Date with the same dictionary definition that you are hoping to use it as.
    Aaron P Scooter Software

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •