>>>Here's the scenario:
>>>
>>>- I create a folder
>>>- I copy an .exe and its .ini into it
>>>- Edit the .ini
>>>- Can't save it, access denied
>>>- Open the properties of the folder, add myself in the security tab and give myself full rights
>>>- Now I can save it OK.
>>>
>>>Why did the chicken cross the road? For security reasons.
>>>
>>>Why do I have to give myself the rights to a folder I just created, to edit a file I just copied into it?
>>
>>I'd seen a similar weirdness under *nix -- and typically it's because something went wrong with the ownership (and typically the weirdness occurs when there's a problem with the group ownership rather than user -- using chown to change group ownership often quickly fixes the problem), or because of a problem in the umask, certain permission bits were forced to off upon creation (resulting situation where you were able to create it but you can't modify it afterwards). It could even more confusing if you're accessing this *nix machine from a Windows system through Samba -- the configuration through Windows may look OK, but a permission problem at the *nix level will cause a problem.
>
>At least in this case it's a known problem, and you see the permission bits in pretty much any file manager. Under W2012R2 and a few others since, I guess, the Vista, it's obscured. You have to look at the still-so-small but stiffly not resizable (grr) property dialog, where you have to click around a lot to unearth the information.
>
>And then there's the similar problem of the gray read-only checkbox on folder properties dialog, which stays gray no matter what you do, which is the windowses' way of telling you that windowses may make some of the files read only while you aren't watching, but since it (windows) doesn't know what it (windows) may do, and can't be sure that the information it gets (from windows) would be 100% correct all the time, it just gives this gray checked checkbox as a hint to this homage paid to uncertainty principle. Which is an explanation you get if you ever get sufficiently pissed off to investigate (i.e. google) the matter.

And how 'bout the fun dealing with how DOSSHELL in DOS 4.0 handled the DOS attributes of hidden, read-only and system? If you managed to set hidden and read-only, it would help you out by setting system too -- but since it doesn't provide an interface to clear system, there was no way to clear hidden and read-only (ran into a few situations where users had done this -- had to use ATTRIB to reset the attributes back). The worst misbehavior I remember with DOS 4.0 was the way the OS install disc (at least with the IBM-DOS 4.0 release apparently this "feature" was missing in the MS-DOS 4.0 release) was how the OS install diskette would silently reformat your harddisk and install the OS (it would seem to take a bit of time to boot, then upon finishing its task it would proudly announce that DOS 4.0 has now been installed).