Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Saturday, October 1, 2016 10:43 PM | 4 votes
Directed here from answers.microsoft.com, probably because this is such a head-scratcher!
Create a folder (say, TestFolder) and at the command-line use attrib +r TestFolder or attrib +s TestFolder to set read-only or system attributes for the folder. Then in File Explorer:
Windows 10 1511 (Tested on all builds till 10586.753)
- Make a copy of the folder with attributes +R/+S on the same partition - Copy has same attributes set as the original
- Make a copy of the folder with attributes +R/+S on a different partition - Copy has same attributes set as the original
- Move the folder with attributes +R/+S elsewhere on the same partition - Folder still has same attributes set as before
- Move the folder with attributes +R/+S to a different partition - Folder still has same attributes set as before
Windows 10 1607 (Tested on all builds till 14393.693 & Insider Preview build 15002)
- Make a copy of the folder with attributes +R/+S on the same partition - Copy loses attributes of the original
- Make a copy of the folder with attributes +R/+S on a different partition - Copy loses attributes of the original
- Move the folder with attributes +R/+S elsewhere on same partition - Folder still has same attributes set as before
- Move the folder with attributes +R/+S to a different partition - Folder loses attributes it had before
Besides the purely puzzling nature of the change in behavior, this has direct repercussions because it means customized folders (with non-default icons for example) lose their customization on being copied/moved in Windows 10 1607. This is because for desktop.ini to work folders need to have either the +R or +S attribute set.
BTW, +R and +S aren't the only folder attributes being lost on copy or move. Windows 10 1607 seems to strip all attributes from copied/moved folders, including +A, +H, +I etc. So this is a general problem and not just limited to loss of folder customization due to loss of +R/+S.
Please fix this bug in Windows 10 1607 ASAP.
Update (Feb. 10, 2017): The bug finally seems to be fixed in Insider Preview build 15019 but the fix hasn't been pushed out to previous Windows 10 versions (1507/1511/1607) yet.
All replies (41)
Sunday, October 2, 2016 5:50 PM | 1 vote
Well tested on 14936 Insider Build and it appears the same, copying the folder with File Explorer with SHR set that was removed. Would seem like unintentional to me so a bug perhaps.
Noticed Robocopy preserves attributes so suggest as a workaround you use that in the meantime.
Sunday, October 2, 2016 7:08 PM | 1 vote
Thank you Mr Happy for responding. Yours in the first proper response I've got to this irksome issue that I've been posting about on multiple fora, providing feedback about etc.
Now the million dollar question is, how would one go about bringing this to the attention of the Windows Shell Team (or whatever group is in charge of File Explorer)? Clearly they need to undo whatever they tinkered with unnecessarily. Can Microsoft employees monitoring this forum, if any, forward this to the concerned people? On top of that if it's not too much to expect, an official acknowledgement of the bug and commitment to fix it in a future version would be awesome.
Wednesday, October 5, 2016 9:10 AM | 1 vote
Hi Robert,
I have done the similar test with same issue.
I will feedback this issue in our platform and also, please submit your testing results on Feedback hub. Hope it can be fixed in the future.
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Sunday, October 9, 2016 4:59 AM
I have found the same issue and thank for your professional summarization. I think this folder copying problem relates to the foundmental functions of operating system. If the change is a major alteration of Windows, Microsoft should announce it and let us know the reason. Otherwise it may be a serious bug. I hope it will be fixed as quickly as possible.
Monday, October 17, 2016 4:43 PM | 1 vote
(Now it works!). I have noticed the same problem since the most recent Windows 10 Update. Is there any solution to fix this?
Tuesday, October 18, 2016 1:09 PM | 1 vote
(Now it works!). I have noticed the same problem since the most recent Windows 10 Update. Is there any solution to fix this?
Just to confirm to anyone reading this, the "Now it works!" above refers to JMFJMFJMFJMF being finally able to post here and does not indicate that this bug has been fixed.
Also I unaccepted Mr Happy's post as the answer because while that workaround may work, I don't want this thread to show up falsely as "solved" (and consequently ignored) until that really is the case.
Tuesday, October 18, 2016 5:18 PM
Well just tested on Insider Build 14946 and the attributes are maintained after copying with Explorer. So progress perhaps be interesting to see if the change makes it into the 1607 release.
Wednesday, October 19, 2016 1:39 AM
Yep, please always keep your Windows 10 up to date.
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Wednesday, October 19, 2016 3:02 PM
Well just tested on Insider Build 14946 and the attributes are maintained after copying with Explorer. So progress perhaps be interesting to see if the change makes it into the 1607 release.
That's great news Mr Happy! Just to be 100% sure, I hope you checked all the 4 cases?
Somehow I doubt they'll backport the fix into a forthcoming cumulative update for 1607. 14946 is of course a Redstone 2 build and that will supposedly be released only 5 months later in March 2017. I only hope there are no regressions in the next 5 months leading to the bug raising its head again. :/
Based on your encouraging post I'm leaving it as the proposed answer for now. Thank you once again for looking into this, and thanks to Kate as well.
Saturday, October 22, 2016 12:02 PM
"Well just tested on Insider Build 14946 and the attributes are maintained after copying with Explorer. " --Mr Happy
"This is because for desktop.ini to work folders needs to have either the +R or +S attribute set."
--RobertJWin
I tested build 14951 but the problem is still the same. I made a comparative experiment among windows 10 preview 14951, 1607-14393.0, 1607-14393.321 and windows 7 through virtual machine vbox.
I found, for a single file, no matter a normal file or the "desktop.ini", the copy don't lose its original attributes. The most important is the folder. This is my experiment:
I created a folder "f" and typed command "attrib f". I found it had no any attributes. Then I altered a customized icon for the folder and type "attrib f" again. I found it had a "R" attribute. And in the folder, a hidden file "desktop.ini" was created. The "desktop.ini" had "A", "S" and "H" attributes. When I copied the folder to another directory, I found the icon of the copy folder restored to the default and its "R" attribute was discarded. And the "A", "S" and "H" attributes of the "desktop.ini" in the copy folder remained unchanged. Finally, I typed "attrib +R f" to restore the "R" attribute of the folder and then I found the customized icon restored.
So my discovery is, for Mr Happy, your test may have somthing wrong. As of the release of preview 14951, the problem is still the same. And for RobertJWin, the attribute of the folder is the key of the customization problem. In my experiment, "desktop.ini" had no any change during the whole period.
If Microsoft think losing attributes is necessary for coping folders in its new operating system, no matter what the reason is, it should at least remain the customized icon of a folder unchanged when its attribute is discarded.
So I would rather believe the reason of the issue is a bug.
Thank you RobertJWin and Mr Happy.
Tuesday, October 25, 2016 4:05 PM
I tested build 14951 but the problem is still the same. I made a comparative experiment among windows 10 preview 14951, 1607-14393.0, 1607-14393.321 and windows 7 through virtual machine vbox.
Now that's really disappointing news because it means either Mr Happy's testing on 14946 missed something, or that MS did exactly what I predicted and the bug has raised its head again in 14951.
And for RobertJWin, the attribute of the folder is the key of the customization problem. In my experiment, "desktop.ini" had no any change during the whole period.
I already know that it's the customized folder's attributes that are important and not desktop.ini's, so that part really didn't need any confirmation. That's why I specifically mentioned "Folder attributes/customization lost on copy or move" in the thread's title and wrote that "This is because for desktop.ini to work folders need to have either the +R or +S attribute set".
Would it be possible for you to provide the results of all 4 tests (2 x copy and 2 x move) run on 2 folders (one with +R and the other with +S) on 14951? That way we can clearly let MS know which operations are buggy and need to be fixed. Thanks!
Tuesday, October 25, 2016 5:20 PM
Well indeed missed the folder bit I think. No longer have 14946 to test again, tested on 14951 and the folder attributes do not get copied.
Thursday, October 27, 2016 5:22 AM
Would it be possible for you to provide the results of all 4 tests (2 x copy and 2 x move) run on 2 folders (one with +R and the other with +S) on 14951?
I got the latest version 14955 and made a comparative experiment on it. My experiment based your operation of copying and moving on the same partition and different partitions respectively.
Now I have completed all the four tests you mentioned.
My conclusion is exactly the same as yours.
R and S Attributes of folders
COPY MOVE
On the Same partition lost unchanged
On different partitions lost lost
In addition, I tested a copying operation of three nested folders with customized icons on the same partition. Having been copied to a directory, each of the R attribute of the three nested folders was discarded and their customized icons were lost.
(I captured and edited many relevant pictures but disappointingly, this forum doesn't allow me uploading them.)
What worries me the most is, if a major folder nesting thousands of subfolders with R or S attributes is copied, how much time does it take to stripping off the large amounts of attributes?
Friday, October 28, 2016 6:43 PM
Well indeed missed the folder bit I think. No longer have 14946 to test again, tested on 14951 and the folder attributes do not get copied.
Thanks for testing again. So that confirms what jiafeiliulangmao wrote, that this bug has NOT been fixed yet. :(
Friday, October 28, 2016 6:53 PM
I got the latest version 14955 and made a comparative experiment on it. My experiment based your operation of copying and moving on the same partition and different partitions respectively.
Now I have completed all the four tests you mentioned.
My conclusion is exactly the same as yours.
R and S Attributes of folders
COPY MOVE
On the Same partition lost unchanged
On different partitions lost lost
Thanks a lot for testing all the cases on the latest Insider Build. Looks like there has been no attempt at fixing this bug yet.
In addition, I tested a copying operation of three nested folders with customized icons on the same partition. Having been copied to a directory, each of the R attribute of the three nested folders was discarded and their customized icons were lost.
(I captured and edited many relevant pictures but disappointingly, this forum doesn't allow me uploading them.)
What worries me the most is, if a major folder nesting thousands of subfolders with R or S attributes is copied, how much time does it take to stripping off the large amounts of attributes?
Not sure, but perhaps it might not take all that long since it would involve just an attribute bit being flipped while each copy is being made. Regardless, this is definitely a breaking change that they need to fix.
(I can upload images just fine. Check whether any browser add-on is blocking things at your end.)
Thursday, November 3, 2016 12:56 AM
I have found a freeware program called Fast copy which works like a charm for copying customized folders intact.
FastCopy v3.25
You can select multiple folders to drag and drop into the source box then drag and drop your destination drive or folder into the destination box and select execute.
Tuesday, November 22, 2016 10:01 PM
I also found this issue a while ago, and several others. This is very, very annoying and i don't want to use other software to make simple file/folder copies on Windows!
Tuesday, November 22, 2016 11:47 PM
I also found this issue a while ago, and several others. This is very, very annoying and i don't want to use other software to make simple file/folder copies on Windows!
Indeed Filipe, neither do I! Something as simple as folder copying/moving being broken (partially) when it was working fine for so many years needs to be addressed by Microsoft ASAP, but it seems no-one there is the least bit concerned about it. Looks like they're interested only in pushing useless apps nowadays and so breaking Explorer is no big deal for them.
I wonder if anyone has had a chance to test build 14971 yet?
Wednesday, November 23, 2016 6:56 PM
Tested on 14971 still folder attributes lost on folder copy.
Friday, November 25, 2016 3:07 PM
Tested on 14971 still folder attributes lost on folder copy.
Thanks for confirming, Mr Happy. So the wait for a fix continues...
Saturday, December 10, 2016 11:08 PM
Mr. Happy, I do hope you can make me happy again :)
Every time I have a new client I open a folder for that client's files. The file structure is the same and has almost 100 folders and/or subfolders. My life was greatly enhanced when I figured out how to customize a folder icon so now they are all color-coded and it is easy to work through them quickly based on the colors.
I am using Windows 10 Pro. A recent upgrade wiped out my ability to copy the color-coded master folder structure to each new client file and I suspect that is the point of discussion here. I am not tech savvy and I have no idea what the responses posted here mean so I am at a loss.
I have not heard of the Robocopy command before but I do know how to get to a dot prompt as administrator and go from there (I learned on DOS). However, every iteration of Robocopy I can come up with does not work so my syntax is off. The ability to copy my master color-coded folders again would GREATLY improve my work life. If you anyone can help me I would promise to drink a beer in their name.
My master folders are kept in c:\data\folders\.* and include multiple subdirectories. Any suggestions?
Thanking you in advance and most desperately yours, Rachael :)
Sunday, December 11, 2016 5:31 PM
The thing about robocopy to me is it is source destination files (not source\files destination as most copy commands).
robocopy c:\data\folders\ e:\data\folders\ * /E /R:3 /W:10
So copies all folders including empty from c:\data\folders to e:\data\folders with retry as 3 times and wait 10 seconds between retries.
Not sure how you are color-coding the folders. If you have issues with this please open and new thread explaining the issues and how you are color-coding the folders what you have tried.
Monday, December 12, 2016 3:06 PM
While Microsoft ignore this bug, 3rd party vendors added workaround to fix folder attributes after copy/move.
Here is tutorial: www.folderico.com/what-if-custom-folder-icon-does-not-show.html
This is very useful app, and at the last update they added option to fix folder attributes if they was lost.
Monday, December 12, 2016 5:25 PM
Thanks synapse, but there's no way I'm ever going to pay for an app just to add +R or +S to my customized folders.
Friday, December 16, 2016 2:08 AM
I have updated to version 14393.576 and the problem has not been solved yet. I found a way to restore the customized icon quickly.
Right click the folder->"properties"->"Customize" tab ->click the "Restore Defult" button in the "Folder pictures" area->OK, then the lost icon of the folder restores.
But this method doesn't support multi-selected folders processing so we have to process the folders one bye one.
To study what the method does for a folder losing its icon, I opened a CMD window and typed the command "attrib foldername" repeatedly to observe its attributes change. I found that when the "Restore Defult" button was clicked, whether the folder had ever been set a customized icon or not, a "R" attribute was set to the folder immediately so its lost icon restored.
This is the only method to change the "R" attrbute of a folder in the GUI environment because in "properties"->"General" tab, the Read-only check box only applies to files in folder.
And the CMD window method of "attrib +R foldername" is not practical because to determin the path of a specific folder is quite difficult.
In addition, the CMD window method also doesn't support batch folders processing because the "attrib" command doesn't support wildcard character such as a*, b*, or *.* .
Wednesday, December 21, 2016 6:56 PM
Right click the folder->"properties"->"Customize" tab ->click the "Restore Defult" button in the "Folder pictures" area->OK, then the lost icon of the folder restores.
Yes, it is well known that you can do this or even reselect the same custom icon as before. Since employing the Customize tab initially added the +R (or +S depending on a registry setting) attribute to the folder (only way desktop.ini can take effect), it is but obvious that employing the Customize tab again will restore the attribute that Win10 1607 stripped from the folder while copying/moving it.
To study what the method does for a folder losing its icon, I opened a CMD window and typed the command "attrib foldername" repeatedly to observe its attributes change. I found that when the "Restore Defult" button was clicked, whether the folder had ever been set a customized icon or not, a "R" attribute was set to the folder immediately so its lost icon restored.
Using the Customize tab in any way (whether the folder had a custom icon or not earlier is immaterial) adds a desktop.ini (marked +H +S) to the folder (or edits it if it already exists), and marks the folder as +R (or +S depending on a registry setting). Naturally once the folder's lost +R or +S is restored any desktop.ini customizations (including custom icon) will show up once again. No offence and not to sound snarky but none of this is news, and I thought you already knew it instead of needing to investigate further.
And the CMD window method of "attrib +R foldername" is not practical because to determin the path of a specific folder is quite difficult.
Hardly. Shift+right-click the parent folder and select Open command window here, then use attrib +R subfoldername or attrib +S subfoldername.
In addition, the CMD window method also doesn't support batch folders processing because the "attrib" command doesn't support wildcard character such as a*, b*, or *.* .
If one was interested one could possibly cook up a for loop (or a batch file employing one) to process multiple folders at once, but that's just unnecessary when there are GUI tools such as NirSoft's BulkFileChanger already available.
The point of all this is, the cause (loss of folder attributes) is well-known and consequently the fix is also obvious (re-assign lost attributes, either from the command line or by using a script or GUI tool or by re-customizing each folder), but this in no way absolves MS of blame or the responsibility of fixing this bug ASAP.
P.S. Has anyone tested build 14986 yet?
Wednesday, December 21, 2016 7:12 PM
Just tested 14986 folder attributes still lost on copy.
Wednesday, December 21, 2016 7:32 PM
Just tested 14986 folder attributes still lost on copy.
Not surprising at this point. Thanks for testing.
Sunday, January 8, 2017 3:37 PM
"Besides the purely puzzling nature of the change in behavior, this has direct repercussions because it means customized folders (with non-default icons for example) lose their customization on being copied/moved in Windows 10 1607."
You are right, RobertJWin! I experienced the same and wasted quite some time searching the Internet for a solution until I discovered the MS Community Forums where I posted my question. I am delighted that you responded within minutes (I just don't know how you could have read my question immediately; is your computer looking for messages of this nature?)
I will forget about the disappearing icon issue because once MS fixes the underlying problem which you ingeniously identified and described in your post, those icons will appear by themselves on the other disk drive since the desktop.ini files have been copied correctly.
Thank you.
Tuesday, January 10, 2017 10:28 PM
I am delighted that you responded within minutes (I just don't know how you could have read my question immediately; is your computer looking for messages of this nature?)
Pure coincidence that I was online and chanced upon your post so soon after you made it, I assure you! :)
I will forget about the disappearing icon issue because once MS fixes the underlying problem which you ingeniously identified and described in your post, those icons will appear by themselves on the other disk drive since the desktop.ini files have been copied correctly.
You can use any of the fixes and workarounds mentioned in this thread so far while you wait along with the rest of us for MS to fix this bug.
Speaking of which, I'm sure Insider Preview Build 15002 brings us no joy either...
Tuesday, January 10, 2017 11:13 PM
Bah tested this on 15002 I got no joy. The hidden attributes lost on file \folder copy with File Explorer.
Wednesday, January 11, 2017 1:05 PM
14393.693 has been tested and the bug remains.
I learned from wiki that the main version code of redstone 2 will be "1704". From the release date may be less than four months but MS doesn't seem to have the willingness to fix the bug.
No offence and not to sound snarky but none of this is news, and I thought you already knew it instead of needing to investigate further.
Sometimes I think maybe MS designed a new rule for some fundamental modifications of Windows operating system in relation to its copying behavior. So I have since tried to find whether there is some kind of reasonability about the annoying behavior and meanwhile, I have learned or tested some temporary measures to cope with the problem.
Now very truly I want to know whether the problem is an imperfect innovation or a low-level bug.
Thanks a lot for your professional and lasting research about the problem. I'm looking forward to a breaking news.
Saturday, January 28, 2017 4:53 PM
Ok, so I just read the following and am feeling fairly hopeful now:
Announcing Windows 10 Insider Preview Build 15019 for PC
- We fixed an issue where certain file attributes, such as +s, would be lost when copying or moving a folder to a different partition.
What concerns me is the mention of "file attributes, such as +s" being lost (instead of folder attributes), and only copying or moving to a different partition being mentioned and not that copying to the same partition is also affected.
So if more than one person can carefully test all the 4 cases above and confirm that the bug has indeed been 100% fixed, we can finally lay this thread to rest and wait for the Creators Update with hope.
Saturday, January 28, 2017 7:42 PM
The file attributes being set to folders maybe a case of semantics. The info on the attrib command sets file attributes, but can also set them on folders, but then are they still file attributes even though set on folders?I digress.
Tested on 15019 and can copy of move the folders and the folder retain the attributes set. So yes appears fixed on 15019 to me.
Tuesday, January 31, 2017 8:58 PM
are they still file attributes even though set on folders?
Just because attrib /i still says "Displays or changes file attributes" because MS never cared to update it doesn't mean file and folder attributes are the same. However probably you're right about the use of file vs. folder in the change log for 15019 being a case of simple confusion.
Tested on 15019 and can copy of move the folders and the folder retain the attributes set. So yes appears fixed on 15019 to me.
Thanks for testing. I'm looking to confirm this myself but am not in a position to play with that build or newer ones in the near future, so further confirmation from more folk would really set my mind at ease. That, plus I hope that there's no regression till the Creators Update is released, or even subsequently.
Saturday, February 4, 2017 11:31 AM | 1 vote
so further confirmation from more folk would really set my mind at ease.
Now the long awaited good news is coming!
Having heard your breakthrough news about the preview build 15019, I have gotten and tested the latest preview build 15025 through my virtual machine. The bug has been removed! I have tested all your four cases carefully. The behaviors of copying and moving have restored to the traditional manner.
But the current 14393.726 hasn't been fixed yet.
Thursday, February 9, 2017 9:41 AM
I'm just new to Win10 and really annoyed with this bug, yet glad to see it has already been fixed by MS :)
Is there any quickfix update for this bug or do I have no option but to wait until it is included on some future official update? I'm on corporate computer using production windows ( currently Microsoft Windows [Version 10.0.14393] )
In the meantime solution provided by "llandyw" seems pretty practical:
(i cannot post a link - it is on www.tenforums.com /customization/62151-problem-copying-customized-folders-2.html )
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Folder\shell\readonly]
@="Set folder re&ad only"
[HKEY_CLASSES_ROOT\Folder\shell\readonly\command]
@="attrib +r \"%1\""
Putting this to a .reg file and merging it to registry creates right-click command "Set folder read only" for selected folder (or folders)
Thursday, February 9, 2017 2:08 PM
Thank you for the clarification, Robert. Indeed I meant that I am finally able to post on this bulletin board. Sorry for not having been clear. As far as I can see on my computer, which is always on and supposedly updated automatically by Windows 10, I confirm that the bug is not fixed (Feb 9, 2017).
Friday, February 10, 2017 4:08 PM
Now the long awaited good news is coming!
Having heard your breakthrough news about the preview build 15019, I have gotten and tested the latest preview build 15025 through my virtual machine. The bug has been removed! I have tested all your four cases carefully. The behaviors of copying and moving have restored to the traditional manner.
But the current 14393.726 hasn't been fixed yet.
@jiafeiliulangmao: Thank you for the additional confirmation! Looks like we'll have to wait for the Creators Update after all for the fix because I doubt whether MS plans to push it to previous versions of Win10 via a Cumulative Update.
Is there any quickfix update for this bug or do I have no option but to wait until it is included on some future official update? I'm on corporate computer using production windows ( currently Microsoft Windows [Version 10.0.14393] )
In the meantime solution provided by "llandyw" seems pretty practical
Putting this to a .reg file and merging it to registry creates right-click command "Set folder read only" for selected folder (or folders)
@KamacD: I don't think there's going to be any Hotfix provided for this, and perhaps the fix won't even be backported to Win10 1507, 1511 or 1607. However only MS can confirm that of course.
I find it easy to simply open a command prompt window and run attrib +r, but perhaps adding it to the context menu might make it simpler for some. When multiple folders are involved I recommend NirSoft's BulkFileChanger instead.
Thank you for the clarification, Robert. Indeed I meant that I am finally able to post on this bulletin board. Sorry for not having been clear. As far as I can see on my computer, which is always on and supposedly updated automatically by Windows 10, I confirm that the bug is not fixed (Feb 9, 2017).
@JMFJMFJMFJMF: So far the fix is only present in Win10 Creators Update Insider Preview builds from 15019 onwards. Unless MS pushes the fix to existing versions of Win10 all non-Insiders will probably need to wait for April when the Creators Update is due to be released.
Monday, May 8, 2017 3:39 PM
"Update (Feb. 10, 2017): The bug finally seems to be fixed in Insider Preview build 15019 but the fix hasn't been pushed out to previous Windows 10 versions (1507/1511/1607) yet."
Does anyone know whether this fix will be automatically applied to updates for all of us commoners, or do we have to do something to implement it?
Monday, May 8, 2017 3:46 PM
"@JMFJMFJMFJMF: So far the fix is only present in Win10 Creators Update Insider Preview builds from 15019 onwards. Unless MS pushes the fix to existing versions of Win10 all non-Insiders will probably need to wait for April when the Creators Update is due to be released."
We are now May 8 and no fix yet for us commoners. Would it come automatically or should we do something to download /activate it (i.e. make it work)?