1. Forum
  2. Usenet
  3. UK.COMP.HOMEBUILT

  • Data Backup Conundrum

    From Jeff Gaines@21:1/5 to All on Sun Jun 15 11:54:42 2025
    XPost: uk.d-i-y

    In my attempts to ensure I didn't lose any data after my server stopped
    running I put 4 x 2 TB SSDs from the server in a QNAP USB3 DAS.

    I then backed up my data from my main PC to two of the SSDs using
    SmartSync Pro, which has been my backup app for years.

    It is set up to copy over all new/updated files but ignore Recycle Bin and System Volume Information.

    My data is on the D drive at D:\Data if that is relevant.

    I left it running, it took much longer than I expected and after it was finished I saw it had managed to convert the relatively small 43 GB of
    data on the source drive into over 800 GB of data on the destination!

    On inspection it seems to have recursively copied the Data directory into itself nearly 20 times and then changed the destination directory name
    from "DB-JGMAIN" to "Data".

    The "desktop.ini" file contains "LocalizedResourceName=Data" which is
    standard when you tell Windows to keep data elsewhere than in the user directory.

    I have used this backup app for donkeys years, it has always copied all
    files including "desktop.ini" and always been 100% accurate.

    I then amended it to exclude "desktop.ini" and it ran perfectly.

    So conspiracy theories territory, why on earth did it do this? Has MSFT
    update Win 10 to take more notice of "desktop.ini"?

    --
    Jeff Gaines Dorset UK
    The world will not be destroyed by those who do evil but by those who
    watch them without doing anything. (Albert Einstein)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Jeff Gaines on Sun Jun 15 18:10:41 2025
    XPost: uk.d-i-y

    On Sun, 6/15/2025 7:54 AM, Jeff Gaines wrote:

    In my attempts to ensure I didn't lose any data after my server stopped running I put 4 x 2 TB SSDs from the server in a QNAP USB3 DAS.

    I then backed up my data from my main PC to two of the SSDs using SmartSync Pro, which has been my backup app for years.

    It is set up to copy over all new/updated files but ignore Recycle Bin and System Volume Information.

    My data is on the D drive at D:\Data if that is relevant.

    I left it running, it took much longer than I expected and after it was finished I saw it had managed to convert the relatively small 43 GB of data on the source drive into over 800 GB of data on the destination!

    On inspection it seems to have recursively copied the Data directory into itself nearly 20 times and then changed the destination directory name from "DB-JGMAIN" to "Data".

    The "desktop.ini" file contains "LocalizedResourceName=Data" which is standard when you tell Windows to keep data elsewhere than in the user directory.

    I have used this backup app for donkeys years, it has always copied all files including "desktop.ini" and always been 100% accurate.

    I then amended it to exclude "desktop.ini" and it ran perfectly.

    So conspiracy theories territory, why on earth did it do this? Has MSFT update Win 10 to take more notice of "desktop.ini"?


    I have no idea what you've done.

    But here is a thread on the topic.

    https://superuser.com/questions/1777997/prevent-windows-explorer-to-use-localizedresourcename-when-renaming-file-or-fo

    Usually, when something happens recursively, it's related to Junction Points.

    https://learn.microsoft.com/en-us/sysinternals/downloads/junction

    junction -s c:\ # This will take longer than it should to run. allusers contains a trap.

    junction -s c:\ > output.txt # Store in a file for post-processing.

    But the thing you have triggered, seems to be a unique second mechanism. Triggered by attempting to rename something in File Explorer, which might actually be under a Junction. While File Explorer seems to be able to deal with $FileName resources, it's unclear whether there is any intelligent
    handling of attempts to rename Junctions. Hardlinks should be OK,
    as they're implemented as multiple $FileName and should be edit-able.

    In any case, parse the above thread and write us a summary of what worked
    and why it worked :-) What you've discovered, this would completely
    escape any utilities I have. I would not know one of those was present !

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Rumm@21:1/5 to Jeff Gaines on Mon Jun 16 11:56:04 2025
    XPost: uk.d-i-y

    On 15/06/2025 12:54, Jeff Gaines wrote:

    In my attempts to ensure I didn't lose any data after my server stopped running I put 4 x 2 TB SSDs from the server in a QNAP USB3 DAS.

    I then backed up my data from my main PC to two of the SSDs using
    SmartSync Pro, which has been my backup app for years.

    It is set up to copy over all new/updated files but ignore Recycle Bin
    and System Volume Information.

    My data is on the D drive at D:\Data if that is relevant.

    I left it running, it took much longer than I expected and after it was finished I saw it had managed to convert the relatively small 43 GB of
    data on the source drive into over 800 GB of data on the destination!

    On inspection it seems to have recursively copied the Data directory
    into itself nearly 20 times and then changed the destination directory
    name from "DB-JGMAIN" to "Data".

    The "desktop.ini" file contains "LocalizedResourceName=Data" which is standard when you tell Windows to keep data elsewhere than in the user directory.

    ISTR the localized name thing is more intended to allow the default
    folder names like "Desktop" to be rendered in international characters. Desktop.ini can also contain other links to apps needed for preview.

    I have used this backup app for donkeys years, it has always copied all
    files including "desktop.ini" and always been 100% accurate.

    I then amended it to exclude "desktop.ini" and it ran perfectly.

    So conspiracy theories territory, why on earth did it do this? Has MSFT update Win 10 to take more notice of "desktop.ini"?

    I expect it is more likely to be the backup program not understanding a junction or hardlink... I have also seen cases where software gets
    confused if you mount partitions into part of a existing directory
    hierarchy (i.e. *nix style). Things like failing to account for the
    storage requirements of the grafted partition when assessing size of the
    tree it is grafted into.

    --
    Cheers,

    John.

    /=================================================================\
    | Internode Ltd - http://www.internode.co.uk | |-----------------------------------------------------------------|
    | John Rumm - john(at)internode(dot)co(dot)uk | \=================================================================/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)