0

I have a Windows server sharing a directory containing a large number of sub-directories.

Each sub-directory has a desktop.ini file which I cannot, for unrelated reasons, remove. (I know how to delete them, but a separate program which we must run on the machine will just recreate them if we remove them so they are, functionally, impossible to remove at the moment.)

Remote viewing of the share has become quite slow since the desktop.ini files appeared.

Since I cannot remove the files and would like to speed up remote viewing of the share, is there a way to prevent en masse the desktop.ini files from being announced to machines connecting to the share?

Alternatively, if the client machines can be configured to not scan and/or to disregard desktop.ini files, this may also solve the problem.

6
  • I don't know much at all about Windows servers, but I have this idea of making the machines that read files on the server be unable of seeing desktop.ini files by making them hidden files and not giving those "users" the permission to see hidden files. This might be totally silly, too.
    – Ariane
    Jan 8, 2014 at 16:46
  • Sounds like an X/Y problem. Are you sure that the desktop.ini files are making share access slow? Have you isolated it to this? Jan 8, 2014 at 16:56
  • It's totally silly, @Ariane ;-) The desktop.ini files are special system files that Windows will want to see regardless of whether or not they're hidden from the user. It must be told in some different way.
    – Richard
    Jan 8, 2014 at 17:01
  • I'm pretty sure this is it, @allquixotic. The problem cropped up at the same time the files appear, doesn't show up for small sets of sub-directories, indexing is on, but, to close the case, you can use the NET FILES command to watch hundreds of access to _desktop.ini_s when someone opens this directory.
    – Richard
    Jan 8, 2014 at 17:02
  • @Richard - If you delete the files, and disable the program that must be ran, do the problems return. This is the only way to confirm if the desktop.ini and/or the program is the reason the problem exists.
    – Ramhound
    Jan 8, 2014 at 17:13

2 Answers 2

0

The right question to ask is how to stop the machines from reading the desktop.ini files in the first place, and from generating the network traffic. The wrong question to ask is how to make the server pretend that the files aren't there, which won't stop the clients from making the requests for those files to the fileserver.

Whenever a directory is marked with the read-only attribute, Explorer displays it according to what's specified in the desktop.ini file in that directory. It sees the read-only attribute set, it goes and attempts to open and read a desktop.ini file. The very simple answer here is to use the ATTRIB command or something similar to remove the read-only attribute from all of these folders. Note that this will remove all folder customization from these folders.

Explorer doesn't let one change the read-only attribute using the properties dialogue. You have to use some other program such as ATTRIB to do it.

Further reading

0

This works on windows 7.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer] "UseDesktopIniCache"=dword:00000000

4
  • Could you clarify how someone would locate this information? Please see How to Answer.
    – Burgi
    Sep 8, 2017 at 8:05
  • This is a new question. Make it so, and I will answer in it.
    – Rupert
    Sep 8, 2017 at 9:49
  • I'm trying to help you improve your answer to prevent it attracting low quality flags.
    – Burgi
    Sep 8, 2017 at 11:50
  • This is a "super user" forum, where people ought to know this FAQ. If you do not have the answer in a FAQ, then ask the question, I will answer it, and people can upvote enough to make it a FAQ.
    – Rupert
    Sep 8, 2017 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.