Transaction FILE is used to maintain logical path / file names and it's a cross-client customizing. I've noticed a rather odd thing in it. We have two DEV clients: one allows cross-client customizing changes and the other doesn't. I ran FILE in the client where the changes were not allowed, got a bunch of messages and transaction opened in display (sic!) mode. This part is perfectly fine.
Then I ran a test and realized a change was needed. So I logged into the other DEV client, where changes were allowed, and ran FILE transaction. Much to my surprise, I got a message that the data is locked by <my user ID>. After checking for other open sessions, I realized that when this transaction is opened in display mode, it locks the data. In this situation it's, essentially, a deadlock, because I cannot possibly change the data where it's locked because of the client setting. But in the client meant for changes I can't change it either because it's locked.
I tried this in an EHP6 system, you might be able to see this too in any QA system - locks are visible in SM12. As soon as you go to FILE, the locks appear, even if you are in display mode:
I checked some other configuration transactions out of curiosity and found no locks applied in other cases.
Trying to be a "good SAP citizen", I opened a low incident on this. But so far AGS a) claimed they can't recreate the issue b) accused me of trying to open the transaction for changes in two sessions (not the case) c) claimed the behavior in display mode is "as designed" (no further explanation as to what's the purpose of such design).
Well, maybe I'm the crazy one, so thought I'd ask here. Does anyone see why would FILE transaction need to apply a lock in display mode? This seems to go against the basic transaction design principles IMHO.
Thank you!