In the process of storing my driver files safely from the PC to the laptop, I used DO to copy them wirelessly to my laptop.
But in the process of copying these folders, DO started popping up that some files could not be copied to a too long path name.
I recreated the whole copy process from Windows Explorer (in Win7 64bit), and IE explorer managed to do it perfectly fine.
I suspect Windows Explorer, by default, switches to DOS-stryle pathnames when it encounters quite long files, and DO doesn't.
Therefor when I do a WinMerge compare between the complete subfolder structure from DO, WinMerge cries out that it cannot find a lot of files, allthough they are clearly present. This I cannot compare if the copy went 100% correct.
Could this be a shortcomming from DO, or do you suspect a user error ?
Please, I need to copy all my drivers to a safe place (laptop) before i replace my motherboards/PC/memory in my PC in a couple of days.
Source PC : Windows7 32bit (DO 10.0.2 32bit)
Destination Laptop : Windows7 64bit (DO 9.5.6.0 64bit)
For example, when I rightclick/properties a file which is just short enough to be detected by DO,
the path in the popup shows :
\MYOWN-PC\down\drivers\Gigabyte GA-Z68X-UD4-B3 (rev. 1.0)\Drivers Win7 32en64 bit\SATA RAID - Marvell Storage Utility (32 en 64bit)\mb_driver_marvell_msu_6series\MSU\EXTRACTED$_OUTDIR\mail\swiftmailer\classes\Swift\ByteStream
when I rightclick/properties a file which is NOT short enough to be detected by DO,
the path in the popup shows :
\MYOWN-PC\down\drivers\GIGABY~1.0)\DRIVER~1\SATARA~2\MB_DRI~1\MSU\EXTRAC~1$_OUTDIR\mail\SWIFTM~1\classes\Swift\BYTEST~1
I'm confused. Explorer did the copy fine but when you use WinMerge to check it lots of files are missing? That doesn't sound fine to me. (Although it could mean that WinMerge doesn't like long filepaths and Explorer worked okay, of course.)
What do you mean "not short enough to be detected by DO" ?
[quote="leo"]I'm confused. Explorer did the copy fine but when you use WinMerge to check it lots of files are missing? That doesn't sound fine to me. (Although it could mean that WinMerge doesn't like long filepaths and Explorer worked okay, of course.)
Well, i guess you're right with WinMerge not liking long filepaths.
Allthough in the process of checking out if DO can do the the comparison, I probably found a bug/inconsistancy in DO's "Synchronize" function.
Please read below.
What do you mean "not short enough to be detected by DO" ?[/quote]
I meant, the files that DirOpus had no problem with copying, showed the normal pathnames when rightclicking -> Properties -> file path.
the files that DirOpus DID have problems with copying (it popped up a message "file not found" during the copy process), showed the DOS styled pathnames when rightclicking -> Properties -> file path.
But now onto the bug with synchronize. (Please tell me if i better start a new thread for that)
While i had the bunch of file copied (8.451 files, 879 maps (including deep subfolder nests), approx. 20 GB data) and WinMerge crapped out about missing files.
I checked out DirOpus' "Synchronize" function to compare them this way, the result told me all files were equal.
Since this is the first time I use the DO synchronize tool (Synchronize scares me, because i think it won't simple compare file byte-by-byte, but will start removing & adding files here and there).
Just for a test, a create 1 new "testfile.txt" inside a nested subfolder on the first system ONLY.
I ran synchronize on this huge folder-nest again, and DO told me both were equal again (allthough there's a file on system 1 which is missing on system 2 ????????)
out of curiosity, I did the synchronize again, but this time, starting from some levels deeper, it there where only about 500 files & 200 (sub)maps to compare, and this time DO's synchronize spotted that 1 file was not on the second system.
So, perhaps Synchronize loses track, and "didn't see" the missing file when it was used with the pretty huge deeply nested content ?
The Properties dialog is part of Windows; Opus just tells Windows to display the dialog for a given path.
Try opening the Properties dialog for the same file in Explorer. It will also show the short path. So I think the short path in the Properties dialog is something that Windows is doing, not Opus. (Unless both Opus and Explorer are doing the same thing. Either way, it doesn't seem important as it isn't a difference between Opus and Explorer.)
From a quick test (echo {filepath$}) It looks like Opus does automatically switch to using short names when sending very long filepaths to other programs. This is probably because many/most Windows programs, and several parts of the Win32 API itself, have problems with paths greater than MAX_PATH=256 characters. But internally most (although certainly not all) of Opus doesn't generally care about very long paths and will cope with them.
Synching with Opus seems to work okay with these long paths. The screenshot below shows where I've created a similar folder structure such that one of the "New Text Document.txt" files doesn't trigger short names in the Properties dialogs (in both Opus and Explorer) while the more deeply-nested one does (in both Opus and Explorer), and then synched that folder to an empty directory, which successfully received both files as a result of the sync.
The problem you're seeing with WinMerge may be that WinMerge doesn't cope with very long filepaths. I don't have it installed to test, but if it's claiming something isn't there, see if it actually is there to find out if it is telling the truth or confused by the long paths.
(Although it could mean that WinMerge doesn't like long filepaths and Explorer worked okay, of course.)