Behaviour by design
I’m busy building and developing a bunch of interfaces from third-party products to talk to SAP via SAP PI. It’s all great fun, until the interaction with the third-party software running on Windows XP had to get going. The interface I’m building reads a text file generated by that software. The text file is written to a directory on the PC and PI polls until it’s ready to pick the file up using ftp.
The interface worked well until PI tried to remove the file: unable to delete the file due to insufficient privileges. I check the ftp server details, checked the ownership of the target directory and ensured all users and their permission were set up correctly. No go.
Trying to change the Read-only attribute of the directory, which was the obvious cause of the issue, caused me a bit of frustration: regardless how often and insistently I tried to turn the attribute off and clicked Apply, the read-only attribute remained.

I found a solution in the Microsoft Knowledgebase under article Q256614. The fix involves the insertion of a new registry key, then modifying the attribute from the command line using the attrib command. All this because folder customization utilizes the Read-only attribute. In my case, the folder was in no way customized and all newly created folders on that system exhibit similar behaviour. It’s an XP system running SP3 and is newly installed.

And the behaviour of that attribute is by design. Fancy that…
Stranger things have happened. Perhaps the folder customization is on a parent folder and this is inheriting it.
Why not change the folder to another destination or position in the directory tree.
Bad design. Bad behaviour. It’s another reason Linux and Mac OS X simply make more sense…