ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Main Area and Open Discussion > General Software Discussion

Dumb question but maybe somebody knows how. Probably a form of Sync.

<< < (2/5) > >>

IainB:
I was interested in this discussion and went to check FreeFileSync and the FreeFileSync - automated backup - Mini-Review, to see if FFS could meet the requirements as described in this discussion thread.

Conclusion: It doesn't look like it can.
Reason:

x16wda:
I think most of the copy/sync utilities I have seen need one consistent criterion for filtering selections. That said, it would be fairly straightforward to write in a scripting language [fill in your favorite here, my choice would be Rexx]. If I can scare up some time over the next week or two I'll have a go at it (although someone may beat me to it).

questorfla:
Yeah.   Probably not an off the shelf issues for sure.  I already posted the first road bump.  Encryption.
Some of these files are copied direct from old server drives.  The old server 2008 R2 (and maybe even server 2003) had cases where the files ended up with EFS encryption but when the drives were pulled no one bothered to save the keys.
Because of the fact that I have all these drives from many years to work with I found that eventually I can find the same file somewhere with no EFS.
But:  In any case where an encrypted file (even if it is one with a zero file length) syncs to the same location of files that are NOT zero length, the EFS files always get kept instead regardless of date or size.  They cannot be overwritten either so I cannot go back.  EFS wins all the time.

If you take a look at my other post about this you can see a pretty nifty script I came up with to look for and make a list of all zero length files on the entire hard-drive.  And surprise !  it works  :)  and just one line too.  (or two lines in batch)

My reasoning was that most of these EFS files had no data because of their lack of keys when copied.  They names are there but no "size".  The script did a great job and even located a ton of trash I can remove but.. It did not find all the EFS files or even close.  Many of these files turn out to be inside whole EFS folders.  So .. I next needed a way to search for Only EFS files regardless of size and that turned out to be a little harder.
Apparently, the fact they are EFS makes them somewhat invisible to many search utilities.  That encryption flag is apparently not so easy to locate or make notes of the path to the file.  

On several sites many SYS admins point out that this is a critical "first thing to do" when working with old data servers becasue of this.  Early EFS setups can easily be transferred forward onto new drives without their keys and apparently all it takes is to put a regular file into an EFS folder and the flag gets set for the file.  So the users unwittingly makes their own files unreadable.  This seems to be an inherited permission though I have not tried so hard to find out, I just want to get this over with.

If someone knows the correct "tag" to use instead of file length, i could just plug it into other script I have and get the same list of EFS files instead of Zero Length files.  End of problem. :)

tomos:
If you take a look at my other post about this you can see a pretty nifty script I came up with to look for and make a list of all zero length files on the entire hard-drive.  And surprise !  it works  :)  and just one line too.  (or two lines in batch)
-questorfla (May 21, 2015, 12:16 AM)
--- End quote ---

where's that (dont see it above)

4wd:
If someone knows the correct "tag" to use instead of file length, i could just plug it into other script I have and get the same list of EFS files instead of Zero Length files.  End of problem. :)-questorfla (May 21, 2015, 12:16 AM)
--- End quote ---

Or just use the cipher command: cipher /U /N >encryptedfiles.txt

If you don't have encryption enabled it'll just bomb out:


Otherwise (I don't have any encrypted files but you get the idea):


I wouldn't be surprised if it required all the encryption keys for every user on the system to be able to detect encrypted files belonging to each user.

You could also probably use Powershell to recurse a tree looking at the extended file attributes, (which is where the encryption attribute hides - the only way to see it from DOS is the fsutil usn readdata command).

Addendum: There's some methods shown on the following page: A Fast Way to Find EFS Folders and Files

Including a VB Script and the EFSInfo command off the Server 2003 CD.

Addendum2: And a Powershell script from TechNet:

--- Code: Text ---get-childitem c:\ -Recurse -Force -ErrorAction SilentlyContinue | Where-Object {$_.Attributes -ge "Encrypted"} | format-list fullname, attributes

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version