Currently, renaming or moving an item in Jenkins is non-trivial:

1. You need to ensure that the item is not currently building
2. If the item is a folder, you need to ensure that none of the child items are currently building.
3. If the item (or any child item) is in the queue, you need to ensure that the queue item is blocked from execution (currently this can be achieved with a QueueTaskDispatcher
4. If the item (or any child item) has SCM polling, you need to ensure that polling is not currently taking place (because that requires writing to the polling log for the corresponding item)
5. If the item (or any child item) has Post-commit Hooks, you need to ensure that none of the post-commit hooks will try and log their progress to a log file in the item
6. If there are additional plugins that store state in side-files belonging to the item, you need to ensure that none of those plugins are trying to write the data

What is required is a multi-level lock service that is aware of items and item groups.

Lock types required:

• Soft Read -> prevents relocation, but allows mutating writes. Can co-exist with Soft Write and Hard Read)
• Soft Write -> no relocation, mutating writes of existing files and creation of new files allowed. Can co-exist with Soft Write and Soft Read.
• Hard Read -> prevents relocation, no writes allowed, can request upgrade to Hard Write. Can co-exist with Hard Read and Soft Read.
• Hard Write -> allows relocation. Exclusive lock.

Most existing use in Jenkins would be of the Soft Read / Soft Write variety.

• A move/rename staying on the same file system would just request a Hard Write lock, do the rename and release
• A move/rename needing to transfer across mounts would request a Hard Read, copy all the files, request upgrade to Hard Write and delete the source before finally releasing the lock.
• A copy would request a Hard Read for the copy and then release when done