Directory compare is as the name states a function to compare two directory structures, including files if you want to, and report back any differences found.
General usage:
You can either read in a directory structure at the time you run the software or you load a previously read and saved file. You can chose to do so on both sides. This gives you the ability to compare two saved states or a saved and current state or two paths that should hold the same data. You can go as far as e.g. read one side, wait a certain amount of time and read the same path on the other side (left / right) and compare what changed.
Options:
Those options are the same for the left and right side. There is no difference in between.
Choose Path
Choose a path you want to read in. This is only necessary if you want to read a structure in right now.
Read List
This starts the actual read process. You can still use the software, since the read-process will occur in the background.
Folders only
Check this checkbox to read only folders in.
Note: A compare against a Folders and Files list with checking files might cause a huge output on missing objects! Check “Folders only” in the compare if you have a situation like this to avoid this. Check the statistics on the root-level to see if you have files on both sides!
Save
Click on Save to save your currently available data into a file. Please note, depending on how many objects you read in, this file might be between several KB to several hundred MB or even more. The export is compressed as far as possible.
Open
This loads a previously saved “inventory”. Note that this will only load what was originally read in. If you didn’t read in file (folders only), there will be no file-information available.
Note:
If you save a huge directory structure, it might take VERY long to load this data into the program. As of now, this is by design.
A future version might change the whole save/open process to a different format that might be faster. As of now, please don’t wonder and be patient, it really can take very long to load a saved file.
To avoid this, don’t try to work on structures with less objects – if possible.
The Tree-Navigators
Both sides (left/right) show a tree-navigator. Other than the NTFS-ACL module, you will not be informed in detail about changes in right etc. – but you might recognize that the color of files/directories is “orange” or “red”. Note the following possibilities for this:
- Orange: a file/folder underneath this folder reported an issue (is red)
- Red: the file/folder might not have been accessible (you don’t have permission to it), the path was to long (Windows reported an issue) or another error occurred. The ToolTip of the object should tell you about the reason this file/folder was marked as problematic.
If everything is accessible and no issues are detected, all the paths should show up as black text (you don’t need to check all the sub-levels, the top-level will be enough – otherwise they would show up as orange).
As you can see, something underneath the orange marked path was wrong. You need to be aware of this, since it will be reported in the compare-output as well.
Details
If an object (folder or file) in a tree-view is selected, you will be able to see additional information in the details section.
Statistics
This will show you information like “Full Path”, “Total amount of Sub Folders”, etc. – the field “Current Level” determines in which sub-level you are. The directory you investigated is “0”, the every path underneath will increase by one (e.g. “C:\Windows\System32\win.ini” would be Level “3”). The “Notes/Issues” field might inform you about any issues that have been discovered, like errors with this object (similar to the tool-tip-text if you hover over the path in the tree-view).
Object Information
You will see the information, if available, like shown in the screenshot above.
Attributes
You will see which attributes are set on the specified object, such as:
- Archive
- Hidden
- Not Content Indexed
- Compressed
- Normal
- System
- Encrypted
- Read Only
- Temoprary
NTFS Rights
Similar to the NTFS-rights investigation, you will see the NTFS-rights for this object here. Note that in this case you won’t see if it is a user or group, since this is investigation does not go as deep as the NTFS-rights investigation.
Compare
You need to have data on both sides (left/right) to be able to start a compare.
Compare – Options
You can choose from the following options before you start the actual compare.
Compare Size
This is only applicable to files. It will compare the file-size no both sides and report back if a difference was discovered.
Compare Dates
Compares the created-time, last-access-time, last-write-time. Any differences will be reported. Note that this might create a huge output, since a simple file-open process might already change a time-value.
Compare NTFS Rights
Compare NTFS-rights is a rather complex function. This will actually compare any NTFS-rights on each file/folder that will be available including the owner SID field.
Please note: If a NTFS right was changed on a folder on one side, it will only be reported ONE time. Even if it will influence any sub-object (file/folder). This is by design and avoids unnecessary output. If a folder on a very high level is changed, and it has thousands of file/folders underneath it, the output would be full of unnecessary reports of NTFS-Right changes and you might not be able to identify sub-level issues.
Compare Attributes
This will compare file/folder attributes. This might cause as well a huge output, like if the archive-attribute was changed because the file was written.
Folders only
Assuming one of the both sides loaded (left/right) includes files, this option will avoid to run a check against those files. Only folders will be checked.
Note: A compare against a folders and files list with checking files might cause a huge output on missing objects! Check “Folders only” in the compare if you have a situation like this to avoid this. Check the statistics on the root-level to see if you have files on both sides!
Compare
The actual compare is very complex. It can take quite a long time, depending on the folder-structure you read in and if you e.g. go down to the file-level.
Example:
Let us assume we have a folder-structure with about 1.000 sub-folders. In average each of those sub-folders might hold up to 10 files, what will result in 1.000 folders + 5.000 files = 6.000 objects. Assuming we have the same amount on both sides, we end up in 12.000 independent compares that need to be done (check left against right and vice versa).
Now, 1.000 sub-folders and 10 files is not even a lot. A check on a structure like this might only run a few minutes (depending on the CPU/RAM/hard-drive speed of the machine you it on). More accurate a numbers past 10 times this high or even more.
Such a huge structure will take quite a long time to compare if your compare everything. Simply just the amount of objects will take time, without even checking them.
Tipp:
It is better to divide checks into areas that actually need to be check, e.g. Departments. Check each department-folder structure independently, or just the area where you want to see changes.
Note:
As of now it is not possible to save a pre-read file and then only read a certain amount of it (a sub-path). This might come in a future version.
Compare-results
Once the compare is finished, you will see the results in the following table. Use the search-function to find specific values. The columns will hold the following data:
Source Side
The source-side is not directly necessary, if only shows where the issue/difference was first discovered, what might be in most cases the left side. The same issue might have come up from the right side, but will not be reported again.
Issue Type
Please see the following list of specified issues that can occur, so you can filter for them:
DataMissing
Either on the left or/and right side where no detailed information available, most likely due to an ACL-read issue or a too long path name.
File Size
The file-size (files only!) was different between the two sides.
CreationTime / AccessTime / ModificationTime
Those are the three different date/time values that are stored with the file/folder. Each one will report separately if a difference was discovered.
NTFS Rights
This only occurs when an ACL difference was discovered.
NTFS Owner
This only occurs when the owner SID (not the name!) is different.
Attributes
If the attributes between the two sides for this object where different, this issue type will be reported.
Missing
If an object was only found on one side, but not on the other one, you will see a “missing” issue. In this case have a look at the “Source Side” column to see where the object exists – the source indicates that the object does not exist on the other side (the not source-side).
Note: If the missing object is a folder, no further investigation underneath this path will occur, since everything from this path on will be missing as well!
Issue
You will see details about the issue that was discovered, depending on the issue, you will even see the dates on the left/right side or what was different in the NTFS-rights or attributes in detail.
Type
This will be either “File” or “Folder” and identifies the type of the object.
Path
Here you will find the full path to the directory/file, including the objects name itself.
Selecting a row in the results
If you click on a row in the results, the tree-views (left and right) will automatically try to navigate to the specified path. If the object was missing on one of the sides, the tree-view will only navigate to the parent-folder on the missing side, but select the additional object on the other side.
This whole functionality helps to visualize and find the reported objects on both sides.
Export
Similar to other tables within the software, you are able to export the compare-results table to a .CSV-File or an .XML-file. In this specific case, there is no difference between the two files, both will just export what you currently see in your table.