| Author |
 Topic  |
|
MossyRock
New Member
36 Posts |
 Posted - May 09 2012 : 21:28:34
|
Hello,
I'm running Macrium Reflect Professional Edition (64-bit), version 5.0, on Windows 7 Professional.
I'm browsing images made on another machine with the previous version (the last version of the 4.x series), and while I can open the image and see the directory structure, whenever I try to open a file, such as a word document, I get a dialog box with this message:
"The directory name is invalid".
The image is encrypted and password-protected, but I've supplied the correct password. I've also checked the "Enable access to restricted folders" box.
I can copy the directory from the image to my computer and the files open just fine. I just can't open them directly from the image.
Can I not open files in images made with the previous version of Macrium Reflect? Or is something else going on?
Thanks. |
Edited by - MossyRock on May 09 2012 21:30:13 |
|
|
Nick
Moderator
United Kingdom
6303 Posts |
Posted - May 09 2012 : 23:22:54
|
Hi
Thanks for your post. Sorry you are having problems.
This is a known issue if the image was created on a different PC, NTFS permissions prevent browsing to the folder, and you attempt to open a file directly in Windows Explorer. As you have discovered though, this doesn't prevent you from using copy and paste to recover the file and/or folder.
Kind regards
Nick - Macrium Support
|
 |
|
|
MossyRock
New Member
36 Posts |
Posted - May 09 2012 : 23:34:39
|
Thank you, Nick.
This didn't start happening until I upgraded my machine's instance of Macrium Reflect to v5.0. When I was on v4.x, I know for a fact that I used to be able to open files from this other machine's images without any issues. I did it all the time as they are images from customer machines and they often have me go into past images to find and recover individual files for them.
Is this something Macrium can fix? If I have to keep copying folders from those images to my machine in order to find things, this is going to create huge problems.
Thank you.
|
|
|
|
Nick
Moderator
United Kingdom
6303 Posts |
Posted - May 10 2012 : 00:59:39
|
Hi
Thanks for getting back.
quote:
This didn't start happening until I upgraded my machine's instance of Macrium Reflect to v5.0. When I was on v4.x, I know for a fact that I used to be able to open files from this other machine's images without any issues
This has always been the case, even with v4.2. I suspect that with other images you didn't have the NTFS restrictions on the users folders or you were accessing a different folder. This only happens if the folders have been made 'Private' on the original PC and the folder you are accessing is nested at least one deep from the root of the restricted folder.
If you Change the permissions on the customers PC to give the 'Administrators' group read access then you wont have a problem with future images.
If you are running Windows 7 then this has greater restrictions. Vista or XP may not give you a problem.
Kind regards
Nick - Macrium Support
|
|
|
|
MossyRock
New Member
36 Posts |
Posted - May 10 2012 : 01:41:41
|
Nick,
I just put old version v4.2 onto my sandbox machine and I could directly open any file in those images, just like I used to be able to do.
My sandbox machine is Windows 7 Pro 32-bit. All of my images, including the ones in question, reside in a Windows Home Server share.
Unless this has something to do with some difference between 32- and 64-bit platforms, something has changed between the two Macrium releases.
Please advise.
Thanks!
|
Edited by - MossyRock on May 10 2012 02:01:52 |
|
|
|
Antony
Moderator
United Kingdom
212 Posts |
Posted - May 10 2012 : 13:52:52
|
Hello,
We are unable to reproduce a successful file open using v4.2 with a Windows Image created on a different Windows system with private folders. This appears to be isolated to Windows 7 systems.
We are looking into possible workarounds for the problem - in the mean time, we suggest copying the files from the image to a disk, which works in both v4.2 and v5.
Thanks
Antony
Macrium Support |
|
|
|
MossyRock
New Member
36 Posts |
Posted - May 10 2012 : 15:21:26
|
Thanks, Antony.
Just want to make sure that I understand what you mean by "private folders" - do you mean folders that don't have the "everyone" permission?
By default, every folder a user creates in Windows 7 is "private" except to other administrator accounts on the same machine.
What platform are you testing this on?
The permissions of these folders I'm testing all have the full control by administrators (othermachinename\administrators) attribute, and are being opened by an administrator account on my machine.
This problem will impact my customer service by making it more difficult for me to identify files in my library of images that I keep here, off-site, for them as a service. When they find out that they are missing a critical file for some reason, they let me know and I go in and locate it and send it to them. Now, I'm going to have to keep copying portions of these images to my desktop in order to examine them.
If the way v5.0 works is truly correct, then I must live with it or find another product and migrate my customers to it. If the way v4.2 works is truly correct, then v5.0 needs to be fixed, or a work-around found.
Thanks! |
Edited by - MossyRock on May 10 2012 15:24:35 |
|
|
|
Antony
Moderator
United Kingdom
212 Posts |
Posted - May 10 2012 : 15:50:56
|
Hello,
Ok, to clarify what's going on with private folders - each user and group on Windows is given an identifier, called a SID. Some of these are common, for example the Administrators group and Everyone, between PCs - some are, however not.
Now, when a user creates a private folder, what they may do is remove all users (including Everyone and Administrators) from the folder except themselves. However, their account has a unique ID that is not present on other PCs.
Now, when you take an image of a disk, including a private folder created like this, and attempt to read it on another PC, Windows looks at the access lists and compares your ID and group IDs against this list - if only the user on the remote PC had access (was the only entry), clearly, you'll be denied access.
This all sounds like you can lock an Administrator out of a folder, which would be bad - however, that isn't the case. Administrators can take ownership of any folder or file and gain access to edit their permissions that way, and insert themselves back in. However - here's the problem: on a read-only image, you can't write the new access control list to the disk!
We use a solution for this (enable access to restricted files), which allows you to open folders even if you do not have permissions - however, we have found an issue with opening files directly in Windows Explorer in subdirectories of folders in images on Windows 7 systems if the parent folder is private as above. The message "The Directory Name is Invalid" is displayed and the file will not open.
This issue has existed since the v4.2 and can be seen in this thread for v4.2:
http://support.macrium.com/topic.asp?TOPIC_ID=3299
We opened various images of Windows 7 and Server 2008 R2 Desktops and opened them on other systems, with a private folder set up as described above.
It sounds like, however, this may be a slightly different issue from what you say - if the Administrators group has access to the folder, you *should* be able to get access.
Have you tried a re-install of Reflect? It is possible that the driver registration has somehow become corrupt and it is worth us eliminating this from the list of potential issues. If that doesn't work, then contact us at support (at) macrium (dot) com so we can arrange further assistance.
Thanks,
Antony
Macrium Support |
|
|
|
MossyRock
New Member
36 Posts |
Posted - May 10 2012 : 16:37:53
|
quote:
Originally posted by Antony
We use a solution for this (enable access to restricted files), which allows you to open folders even if you do not have permissions - however, we have found an issue with opening files directly in Windows Explorer in subdirectories of folders in images on Windows 7 systems if the parent folder is private as above. The message "The Directory Name is Invalid" is displayed and the file will not open.
We opened various images of Windows 7 and Server 2008 R2 Desktops and opened them on other systems, with a private folder set up as described above.
Thanks, Antony.
Yes, what you're describing above is definitely not the case here - the folder permissions have not been modified in any way by the user - they would have no idea about how to do this. The folders and subfolders are just the garden variety folders that users create as the need arises, with the default permissions given by Windows.
I just want to make sure we're on the same page - have you tried opening a file in such a garden-variety folder from another machine's image with v4.2, a folder that has not been rendered private by the actions you described?
This would be good to know before I go through an uninstall and reinstall and probably lose all my backup jobs I've set up in the process.
Thanks. |
|
|
|
Antony
Moderator
United Kingdom
212 Posts |
Posted - May 11 2012 : 08:51:17
|
Hello again,
quote:
I just want to make sure we're on the same page - have you tried opening a file in such a garden-variety folder from another machine's image with v4.2, a folder that has not been rendered private by the actions you described?
Yes, and that seems to work fine.
quote:
they would have no idea about how to do this.
On XP, there's a feature called "make this folder private" when using simple folder sharing which essentially does all of the above permission changes for you, without the user ever needing to go near the NTFS security dialog - as such, they may have inadvertently done this, which is why we originally thought this was the cause. The feature in question is this:
https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/windows_make_folders_private.mspx?mfr=true
quote:
This would be good to know before I go through an uninstall and reinstall and probably lose all my backup jobs I've set up in the process.
Your settings should be preserved including backup jobs etc, so you shouldn't have a problem there.
Thanks,
Antony
Macrium Support |
|
|
|
MossyRock
New Member
36 Posts |
Posted - May 11 2012 : 14:22:59
|
Antony,
Ok, so your results with v4.2 agree with mine - v4.2 opens files just fine in standard folders with default permissions.
Now, what happens when you try to open the same files in v5.0?
Thanks |
|
|
|
Antony
Moderator
United Kingdom
212 Posts |
Posted - May 11 2012 : 15:20:34
|
Hello,
quote:
Now, what happens when you try to open the same files in v5.0?
The same file works fine for us - in addition, I've looked into the code and the image mounting process has not changed since version 4.2. So V4.2 and V5 behave in exactly the same way.
Thanks,
Antony
Macrium Support |
|
|
|
MossyRock
New Member
36 Posts |
Posted - May 11 2012 : 16:49:34
|
Antony,
Are you using an image created in v4.2 or v5?
The image I'm using for testing was created in v4.2.
If you're using an image created in v5, can you try one created in v4.2 and see if its files can be opened by both v4.2 and v5 so our test bases will be identical?
Thanks. |
|
|
|
Nick
Moderator
United Kingdom
6303 Posts |
Posted - May 11 2012 : 17:23:14
|
Hi
Thanks for getting back.
There is no difference between v4.2 and v5.0 as far as image mounting is concerned. Both will open images created with either version identically. This has been checked many times.
Please can you try re-installing v5 to see if you have a driver installation related problem.
Can you also confirm whether you receive the "The Directory Name is Invalid" when opening files under another directory such as 'c:\Windows' (notepad.exe for example) or is it just the users folder?
Kind regards
Nick - Macrium Support
|
|
|
|
MossyRock
New Member
36 Posts |
Posted - May 13 2012 : 02:29:08
|
Nick,
I uninstalled and reinstalled v5. The problem remains.
I was able to execute notepad.exe stored in the windows directory in the image.
I am seeing a definite pattern, though: with v5, I can open files successfully until I get to two or three levels deep in the directory structures, and then that's when it starts failing.
With v4.2, I can go as deep as I like and I'm always be able to successfully open the files.
I'm not seeing any differences or patterns in any permissions of the folders or the files themselves that would account for this.
With the user folders, the problem seems just to be tied to directory depth. I went six folders deep into the Windows subfolders and I was able to open files.
Please advise anything else I should look for or test.
Thanks.
|
Edited by - MossyRock on May 13 2012 02:35:39 |
|
|
|
Nick
Moderator
United Kingdom
6303 Posts |
Posted - May 13 2012 : 09:45:01
|
Hi
Thanks for getting back and for your detailed explanation.
If you are seeing the issue only underneath the users folder then this means that the folder has been set 'Private' as explained previously. It's only possible to set *users* folders 'Private' in Windows using the simple file sharing setting.
The reason that the issue happens when you are two levels deep or more is because the way Windows Explorer works in Windows 7. It's checking for 'List Folder Contents' permissions on the full path and fails when a private folder is found in the hierarchy at least one level above the current folder. It isn't using the kernel stack to do this so our 'Enable Access to restricted folders' solution doesn't work. This doesn't prevent browsing folders or file copying though, just direct opening. Note: XP and Vista OS's do not have this problem.
If you can directly open a file in a folder nested beneath a private folder in Windows 7 with either version of Macrium Reflect then this is not something we have seen before. It may be related to a Windows Explorer policy setting. We will investigate this and may need to contact you requesting more information about your Windows settings.
quote:
With v4.2, I can go as deep as I like and I'm always be able to successfully open the files.
If this is a Windows 7 installation then please install v5 on this PC and confirm that you are still able to directly open these files. This will confirm that there is a configuration difference between the Windows 7 installations. If Reflect v5 behaves differently to v4.2 on the same PC then we are currently at a loss for an explanation and we may need to request remote access to your PC to investigate further.
Alternatively, if you download and install free Explorer2 lite then this doesn't have the same issue as Windows Explorer:
http://zabkat.com/x2lite.htm
Kind regards
Nick - Macrium Support
|
Edited by - Nick on May 13 2012 12:54:54 |
|
|
|
Topic |
|
RSS Feed
KB
The Directory Name is Invalid
Forum Locked
