Deny Deleting a folder on Windows

Problem:
Setting the Deny Delete NTFS permission on a folder in Windows still allows me to delete it.


The Story:
Today I had a tricky issue. For some reason when I delete a movie from uTorrent it also deletes the parent directory which is the Movies folder. The data is not lost because it's a mounted NTFS Volume, but it's annoying to recreate the folder and remount it in Disk Management. So I thought it would be great to deny delete on that folder while allowing all operations below the parent. Setting Deny Delete to Everyone still let me to delete the folder, so I kept googling with no results.



Solution
Set the following permissions on the folder that shouldn't be deleted (in my case the Movies folder); leave all other permissions untouched:

• Deny Delete
• Deny Delete subfolders and files
• Apply to: This folder only

Importing Project from JIRA OnDemand to Standalone

This week I had to import some projects from JIRA OnDemand (atlassian.net) into our company Standalone JIRA.

OnDemand JIRA Version: 6.0-OD-01

Standalone JIRA Version: v5.2.1#813

Frist, I took a full backup using JIRA Backup Manager on the source JIRA and copied over on the Standalone server to .\Appdata\JIRA\import.

Then went to System -> Import & Export -> Project Import where the fun began.

This data appears to be from an older version of JIRA. Please upgrade the data and try again. The current version of JIRA is at build number '813', but the supplied backup file was for build number '6001'.

JIRA OnDemand is always a little bit newer than the Standalone released version, but the problem is that JIRA thinks the two backups are uncompatible. To correct this, I had to edit the entities.xml file from the backup. Actually, there's a lot of work in that file so what I did is I deleted the "data" folder from the archive so the extract - repack will go smoother. I used Total Commander to open the zip because it allows to edit the file directly in the archive. Configured Notepad++ as the editor because it's faster on large files than Windows Notepad.

To hack the version, I had to find this:

<OSPropertyString id="10047" value="6001"/>

and replace with

<OSPropertyString id="10047" value="813"/>

The next problem was with the plugins, which were also newer on the source JIRA.

The backup project 'IPM' requires custom field named 
'Rank' with full key 'com.pyxis.greenhopper.jira:gh-global-rank'. In the current 
instance of JIRA the plugin is at version '6.0.8', but in the backup it is at 
version '6.0.8-rc2'. 


The backup project 'IPM' requires custom field named 
'Release Version History' with full key 
'com.pyxis.greenhopper.jira:greenhopper-releasedmultiversionhistory'. In the 
current instance of JIRA the plugin is at version '6.0.8', but in the backup it 
is at version '6.0.8-rc2'. 


The backup project 'IPM' requires custom field named 
'Sprint' with full key 'com.pyxis.greenhopper.jira:gh-sprint'. In the current 
instance of JIRA the plugin is at version '6.0.8', but in the backup it is at 
version '6.0.8-rc2'. 


The backup project 'IPM' requires custom field named 
'[CHART] Date of First Response' with full key 
'com.atlassian.jira.ext.charting:firstresponsedate'. In the current instance of 
JIRA the plugin is at version '1.10', but in the backup it is at version 
'1.10.4'. 


The backup project 'IPM' requires custom field named 
'[CHART] Time in Status' with full key 
'com.atlassian.jira.ext.charting:timeinstatus'. In the current instance of JIRA 
the plugin is at version '1.10', but in the backup it is at version '1.10.4'. 

Being lazy, what I did is searched for all instances of "6.0.8-rc2" and replaced with "6.0.8" (including the quotes) in entities.xml, being the latest public Greenhopper version. Same with "1.10.4" -> "1.10"

The next issue was with user mapping. The users at atlassian.net had different usernames then in Active Directory. JIRA gave me the list of users that have this problem, and I had to update entities.xml for each of them. So I searched for example for "lrog" and changed in "levente.rog" that corresponds to the username in AD. Repeated that for all problematic users.

I could have done the same with the mismatching groups, but I'll just manually assign roles for the new groups after the project import.

There were some unresolved issues left:

The custom field 'Billing Key' will not be imported because the custom field type 'is.origo.jira.tempo-plugin:billingKeys' is not installed.

We are not using the Tempo plugin so I'll just ignore this error message

Unable to import custom field '[CHART] Time in Status'. The custom field type does not support project imports.

Not sure where that comes from

Unable to import custom field 'Sprint'. The custom field type does not support project imports.

That's a big issue, not sure how am I going to solve this. JIRA-28748 is tracking this but that's not a big help at the present.