Why does Unity unlock a read only file?

I lock a file using svn (so it can not be altered) but low and behold the immortal Unity just unlocks it so we can all save over each others work.

Is Unity designed to be awkward?

 

Anyone from Unity Team care to comment on why this was allowed to happen?

 

Hey Spinex,

Doesn't svn lock tell the repository to stop other people from making commits? (I must admit to not being an svn expert, but I've used lock/unlock to give me exclusive access to a file and know that no other user can change the file in the repository. I have never thought of it as marking a file on disk as read-only, but I guess that make sense for people who have updated from the repository, and helps them know that the file cannot be changed.

Consider submitting a bug report for this. I am not saying this is a Unity bug (in the sense that Unity is just reading and writing files on disk, and perhaps does not know that you have locked a repository file using svn).

If you can give us some simple repro steps one of the test team can look into this for you. Filing a bug report will give us your hardware details and the steps you give us will help us reproduce the same behaviour that you see.

Thanks,
Graham

 

Thank you for all replying.

Hopefully next patch this will be fixed as its quite a serious issue especially for companies working on the same file.

But I am very pleased that this is going to be adressed.


For anyone who wants to reproduce this issue follow these guidelines, make your Unity scene file "Read Only" in the file "Properties". Now open it up in Unity and "Save", right click and check the properties and you will notice the "Read Only" flag has been deactivated.

Cheers Unity guys.

 

Unity does not clear the flag actually but deletes the files and rewrites them, as such this flags are worthless as long as you have the priviledge to delete files.

What you would need is a system that keeps an eye on the file.
You could try filehamster plus + team plugin if it does the job you want it to do, because SVN and most other VCS won't do it, they elementally only prevent commits on locked files, they don't care about you modifying your local file. (they only check the state at update, commit, checkout not in realtime)

 

Was this ever fixed? If not, how are you suppose to work on the same project with multiple people??

Or do you just communicate well between team members and keep your user specific work (e.g. a prefab you're working on) isolated in a user folder inside the project and other users know not to touch it?

For scene files do you have users duplicate the scene for their own personal scene that they can use to create / modify prefabs within and then lock the main scene when it comes time to integrate the prefab into the main scene?

Unity really needs an SVN workflow page in their docs...

 

There was nothing fixed as there is no bug with that.
Thats how its meant to work.

I don't see a problem working within teams as you don't lock files that are meant to be used in the team. You lock files that only you are meant to update and a simple mail with "teaching lessons" by rolling back other peoples changes helps a lot getting that to work.
Scene file overrides also can easily be overcome as you must assign distinct devs to management of specific scenes anyway, all others get distinct prefab in the scene to allow them to modify stuff in there to then only update the prefab and alike.

Its also important to keep in mind that people see what they want to update and where they have collisions they need to resolve and as prefab /scenes don't do it automagically, they know exactly that they altered something they were not meant to


and you won't find svn workflow pages as unity does not support SVN. Unity supports VCS, what you do with it and which system you use is up to you and your problem basically. The unity supported VCS is the asset server technology

 

But steffent from Unity just said it was an issue... If this is how it's meant to work then how do you avoid constantly having conflicts? If the files get deleted and re-written regardless, then why lock anything? I'm not sure what workflow you're exactly describing...can you describe more of a step-by-step process?

My understanding of locking is that it's meant to avoid conflicts between binary files, it's not about using or not using a file between team members: if the file is in SVN (binary or text), it's being used by the whole team and therefore can potentially be modified by two people and result in a conflict.

Just based on the sheer number of posts about people screwing up SVN + Unity, I think there's a clear need for Unity to document this workflow.

 

Might be that there is somewhere an issue. But I wouldn't hold my breath on the when, cause unity never respected any file and folder flags in its years of existance so its "nothing new that just recently broke".

And yes, thats the question, why lock it if you know that nobody cares for it.

Thats the theory behind locking yes.
In reality, all locking does is preventing people from working unless you sit in the same office at the same working shifts.
I've yet to see anything good to happen from it in an environment where art and code meet and are inter related, where the work times are not the same or where they don't work at the same place or in short: for any indie and small company work environments around the globe.

And yes your whole team could potentially modify it.
Thats why you need to define responsibilities within the team, why the base of any development - community - is that fundamental, cause then they know what they are entitled to change and what not and anyone ignoring it learns it the hard way if his change is just overwritten in case of a conflict. If the communication is that bad that you have such problems regularly, you will not get a usable product anyway so most teams resort the communication more sooner than later as the frustration curve skyrockets in no time (as it does with file lockings on concurrently used and required files)

Multiple people on 1 scene for example requires that each dev aside of the one with the assigned authority over it, has 1+ prefabs within which he works and sets up stuff. he can then commit them which will automatically update the scene for all others.

That won't change anything as documentation does not cover stupid actions from users nor prevent them and thats whats causing the trouble here.
Also it would surely give a lot of grief if the first line would be "If you like your repo and project state, don't grant artists access to it", independent of how fair and adequate it is in most cases (thats why the Asset Server can be a serious option - artists on SVN requires some correspondingly userfriendly software like smartSVN)

A first step for unity projects would be looking for VCS that store changes in a smarter way so they have at least a chance working with binary, like GIT (if you hate 80 tools, look at smartGIT) or mercurial ("the single app" incarnation of git)

Then the general steps normally are:

1. Each scene that has more than one dev working on has a designated designer / owner. only that person is entitled to commit changes / grant others the right to commit a new version

2. If a scene is used by multiple users, the other users get own prefabs in it to work on and modify and commit. this way the scene for all will be updated without collisions

3. don't work for hours / days on something to do a massive commit. if you do small ones you also can easier grant others the temporal right to do a commit. if you do larger ones you don't have the option due to the lose of work.

4. Don't move around folders in unity if they are versioned unless you delete all svn folders manually to readd the stuff to SVN as it will otherwise become dead folders


If you go with svn, I highly recommend at least trialing smartSVN.
I've been using tortoise svn for years and smartSVN for productivity is a massive step ahead thanks to move detection and auto delete and add detection. it saved many hours where missing stuff or orphaned stuff otherwise would have caused a lot of trouble (our project is over 3.4GB in size, several thousand files and metas)

 

Hmmm..I think I hear what you're saying, and I appreciate your help, but I guess I'm not really convinced that better communication is the solution to avoiding conflicts. SVN locking works with Maya binary files, so in theory Unity just needs to work the same way...then you could setup SVN auto-lock properties to lock the Unity binary file types and people wouldn't be able to modify the read-only files. If you're working in remote locations and can't get a hold of someone to remove the lock you can just steal locks from them, no? I think I'd rather steal a lock than constantly have to communicate hour by hour who is going to edit what in the project..

Also, it's not clear to me how you segregate prefabs between different team members. Different prefabs being edited by different users can have shared dependencies, in which case I would think you'd have trouble avoiding conflicts because two people might edit the same dependency...

 

Lock stealing is no option as you potentially scrap hours of work as it can't be merged.

You will only do it once or twice and then start searching for a new designer / allrounder as nobody accepts work of hours to be scrapped due to someone ignoring the development practises put forward along the team that blattantly.
But its rather rare that it is really a problem, at least if you get the primary source for trouble on SVN out of the way and that are artists (sorry guys, I know there are exceptions, but the other 95% just are more trouble on a VCS than they help ). We all know they tick different than coders and they have their own form of working which just doesn't suite versioning systems like SVN out of my experience. Most projects I've been on didn't allow the artist to mess with the repo, they either had to send in packages to the responsible designers (who then also did required cross merges) or were on an own repo / asset server with someone then doing the syncing to the real repo.

Also you don't have to communicate hour by hour, at least not if the basic team setup and responsibility was not rather indepth messed from the start. People aren't switching their field of responsibility and their tasks on an hourly base, so you can plan ahead on when who is working on what to minimize the overlaps.

Exception would potentially be a real MMO project (15+ team members) but anyone approaching Unity for that when HeroCloud is around can't be helped anyway out of my view I fear. (using webplayer only targeting would be the only acceptable reason for it and there people just have to realize how expensive it will come them to go with unity when you need teamwide pro licenses, have to pay 5-6 figurefee to unity per year for browser cache licensing and have to develop your own client - server architecture and editor extensions)

As for dependency: thats something that has to be worked out on case to case base, often it can be avoided as unity happily enough does not support prefab hierarchies, which reduces the chances of multiple other prefabs requiring it.
Also it must be kept in mind that all tasks related to one topic are normally under control of one designer as such the amount of overlapping dependencies commonly is not as high as one might think or fear (and if you are an indie you might potentially not have more than 1-2 persons even doing this job).
Keeping the prefabs simple and focused additionally helps.
Its not trivial to solve it, agreed, but it can be solved if the people know what they do and have discipline.

 

Hi Unity Team,

I really need this fixed as my team is using perforce which sets all the files you haven't checked out as read only and Unity is just overwriting everything making it very hard to work with in both working out what files need to be checked out and the fact that exclusive checkouts don't work. This is the first time I've encountered a problem with this. Ideally, I'd just want a message box to say the file is read only and cannot be modified.

Can you give me an ETA when this bug will be fixed?

Thanks,

Mark

 

I don't believe that there can possibly be any reason that Unity can not respect read-only file flags. Telling us, the users, that we need to be more disciplined because Unity can't respect read-only file flags is offensive. For such a simple bug, either fix it or explain why Unity is different, with respect to read-only file flags, from every other application. As for setting the read-only flag as part of our workflow (Perforce or otherwise), it should be at the discretion of the user, not the application.

 

Can we add an option to Unity to respect read-only files?

 

Unity needs to respect read-only file flags. Any time it attempts to overwrite (or delete and rewrite) a file that is marked read-only, it should warn the user and provide the option to cancel. Please ignore all discussion of SVN, version control, workflow, etc. on this thread, that's just noise that obscures the basic issue -- if a user has decided that a file should be read-only, then Unity shouldn't write to that file without at least asking.

This has been "on our list of things to do" for three years now -- can someone from UT please comment? Is there an ETA?

If you want this addressed, please vote on the feature request.

EDIT: Looks like an AssetModificationProcessor could do the trick -- the documentation even suggests using this for integration of external "VCS solutions like Perforce which require locking of files".

EDIT 2: No joy. Turns out the AssetModificationProcessor API is part of the work-in-progress on external version control integration, and is only available if you have the Asset Server license (which sort of defeats the purpose). If you don't have the license then AssetModificationProcess is an empty class, presumably because the implementation is compiled out of the unlicensed build. (I do have Unity Pro, but not the Team/Asset Server license.)

 

On your list of things to do? 3 years later and still Unity ignores the read-only flag AND trashes it back to R/W.

Honestly, how simple, this is schoolboy stuff.

 

Please fix this for the love of god. Also, Dreamora, your arguments that it's doing the right thing are seriously ridiculous. Respecting the file flags will allow people to work properly with locks, while still allowing insane workflows based on 'discipline' instead of locks. There's absolutely no reason not to do this 10 minute code change.

 

This is very a frustrating issue. It'd be great to see the functionality changed.

Please vote on the feature request to have Unity respect read-only file permissions.
- http://feedback.unity3d.com/unity/all-categories/1/hot/active/the-unity-editor-should-not-auto

 

Dreamora,

That is the most narrow and sad look at "team work" I have heard !

Team work IS NOT about diving things up so that each person has their unique set of responsibilities that do not interfere with anyone else! Teamwork is about "helping" each other out and coming up with a coherent solution. Yes, things should be dived up properly ofcourse. But in any application the interaction between the different initially unrelated components is CRUTIAL and locking a file is just a way of telling someone else "Hey I am on this right now. IF you need to get to it. ONE, figure out if you truly need to be in this file and two wait a bit until you see the changes I have made so you can properly merge your changes". Carving a cubby whole for each member so no one touches each others stuff is definitely not the solution. If you do that all the time you are probably going end up with a bunch of duplicate work.
In addition, locking files is also a great way to get a quick view of what everyone is working on. Locking a file is a great reminder that you are not working on this on your own. Locking does not mean you can't work any more, it just mean you better be ready to do some merging and respect others changes. In any case readonly attributes should most definitely be respected. Regardless of the reason someone is locking that file.

 

Our team just started using Unity (Pro) and this is our biggest problem at the moment.

Any news on the fix or any ways to go around this? We're using Perforce without the Team License, and as mentioned before the Maya files etc. work well but the scenes don't. Really frustrating!

 

This problem still exists.

Dreamora: you are wrong about the way SVN lock works, it is not a server-side only thing, it marks the file as read-only to prevent local changes. Unity ignores this and overwrites the file anyway.

 

Yeah, this is pretty frustrating, so I just hacked together a fairly simple fix for this. It only works for Windows, but if there is any interest in it, I can probably get a GitHUB repository set up so people can grab source / binaries.

The "solution", which is a combination of an executable and a dll, is to modify Unity itself (in memory only - not on disk), such that any changes to read-only flags from within Unity are blocked. That, plus a little bit of editor script to warn on read-only files makes it pretty usable. It works on Windows 7 (and quite likely Windows 8, and even possibly earlier versions).

It's essentially a very simple dll injection / hook.

I'm testing it now, and if anyone would like to help me test it, I'd be happy to shoot you my current cut...

Ben

 

If anyone reading this is struggling with this same issue, I solved it with this Editor script. I'm not sure if you need a Team/Asset Server license for this to work. It keeps read-only files from being saved and pops up a warning dialog. The dialog text I chose was suitable for my team, change it to whatever makes sense for you.

Name this NotifyForLockedFiles.cs and place it in your project's Editor directory:

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3. using System.Collections.Generic;
4. using System.IO;
5.  
6. public class NotifyForLockedFiles : UnityEditor.AssetModificationProcessor
7. {
8.    public static string[] OnWillSaveAssets(string[] paths)
9.    {
10.       List<string> pathsToSave = new List<string>();
11.  
12.       for (int i=0; i<paths.Length; ++i)
13.       {
14.          FileInfo info = new FileInfo(paths[i]);
15.          if (info.IsReadOnly)
16.             UnityEditor.EditorUtility.DisplayDialog("Failed to check out file!",
17.             "Sorry, but " + paths[i] + " is read only! Someone else probably also "+
18.             "has it checked out, go talk to them. Unity couldn't check this file out, "+
19.             "so you won't be able to check this work in unless they revert theirs.",
20.             "Damn, okay");
21.          else
22.             pathsToSave.Add(paths[i]);
23.       }
24.  
25.       return pathsToSave.ToArray();
26.    }
27. }

 

Well done Ryan!

There was one error in the code...Here is the fix for those that may not have found it.

Code (CSharp):

1.  
2. public class NotifyForLockedFiles : UnityEditor.AssetModificationProcessor
3.     {
4.         public static string[] OnWillSaveAssets(string[] paths)
5.         {
6.             List<string> pathsToSave = new List<string>();
7.  
8.             for (int i = 0; i < paths.Length; ++i)
9.             {
10.                 FileInfo info = new FileInfo(paths[i]);
11.                 if (info.IsReadOnly)
12.                     UnityEditor.EditorUtility.DisplayDialog("Can not save.",
13.                     "Sorry, but " + paths[i] + " is Read-Only! Please Save as another name.",
14.                     "Ok");
15.                 else
16.                     pathsToSave.Add(paths[i]);
17.             }
18.  
19.             return pathsToSave.ToArray();
20.         }
21.     }
22.  

 

So it's 9 years since this issue was brought up and there is no real solution to this issue?

One solution is that Unity should have a read-only mode for assets that are marked read-only on disk. When a user attempts to modify them, Unity should then ask if they wish to check-out this asset. This is what our previous engine did (from the start) and worked quite well for 15 years of making games.

I'm not sure this is a bit more difficult to do with Unity's UI setup, so is there any way that it could at least warn the user as soon as a change is detected to a read-only file? The editor obviously knows which assets have been modified, so if there was an event or just a popup that said something like "You've modified a Read-Only asset. Do you wish to check it out now?" that would go a long way to keeping people from potentially losing work. Possibly a new event in the AssetModificationProcessor???

Trying to do something when the user finally decides to save could cause a lot of headaches and wasted time if they make many changes and then realize the file was already checked out.

 

Just to make this issue clearer, right now it is very easy to lose work while working on scenes on a team using the built-in Perforce integration (and presumably PlasticSCM):

• User 1: Opens a scene normally in Unity. Makes changes, saves changes (despite the scene being read-only). They are never prompted to check out the file or that it is even read-only. Their changes do not appear in the Version Control panel.
• User 1: Thinks they are good (there's nothing showing to check in or maybe they just didn't notice the scene was missing from their list of submissions) and continues working on other things.
• User 2: Remembers to properly check-out the same scene first and then makes changes to it, saves them, and checks their changes in.
• User 1: Performs a Get Latest to get the latest changes and then realizes that all the changes they made to the scene are lost.

Losing work because Unity blindly obliterates the read-only flag and fails to inform users that they are attempting to modify a read-only file is not acceptable. I know of no other application where this is valid behavior.

Please add a way to properly warn the user before changes to a read-only asset are made (ideally prompting for checkout of that asset and updating its dependencies). Or at the very least add a notification or way to get the list of modified assets so that we can add a warning as soon as someone attempts to modify a read-only file.

 

OMG I cannot BELIEVE this.

Unity has just DESTROYED WEEKS OF MY WORK because important read-only files were overwritten.

And now I find this forum thread that is 10 YEARS OLD!!!!!

People at Unity, what the hell is wrong with you??? Why is there no fix for this??????? Why would you even DO such a thing in the first place???????????????

Write-protecting files is something that happens on the operating system level. WHY THE HELL WOULD ANY APPLICATION CHOOSE TO OVERRIDE THIS.

This is simply ASKING FOR TROUBLE.

BAD, BAD ENGINEERING.

It is a mystery to me why Windows would even allow this to happen. But that is another topic.

 

Dude, I agree that this is a flaw in Unity. But let's not place all the blame on Unity here.

If you go weeks without making a backup of important files, "this is simply ASKING FOR TROUBLE." Version control like git or subversion, Time Machine, Backup & Recover, rsync, even a zip file archive, would have saved the day. Pretty much every time you get to a stopping place between trying a feature in one build and starting to look at implementing the next feature, make sure you've committed your files to a backup and/or version control repository.

 

So it has been about 10 years and this is interfering with out file lock version control system. Can we please address this issue.

 

For those struggling with perforce integration here's a script that checks a scene's status when making an initial modification. It also prevents overwriting any readonly asset (using the code above)

 

I also have this problem. I wanted to use it on the meta files of materialvariant which are constantly changed every time different people open the project and we don't even touch them. So please either make Unity respect the file permissions or make it so that it won't randomly make changes in the meta files of materialvariant files. This is making git workflow insanely annoying for us.

 

well crap. didn't think that something as clearing read-only flag for a file will be possible but unity ceases to amaze me. I found that during researching git-lfs locking and that makes it pretty useless when unity just ignores local filesystem locks.

 

is not that they hide this