Community
Participate
Working Groups
- a remote unix system - create a file a.txt and A.txt in the same directory - windows as host --> try to edit both files....
Kushal, I'm assigning this to you as I think you had recently looked at something to do with the conventions we use for storing temp files.
*** Bug 185791 has been marked as a duplicate of this bug. ***
This has always been a problem. We'll need an alternative way to map filenames that are different only in case.
Would that caching problem also affect the EFS provider, or does EFS work around the file cache? (I think it does since it always returns streams... at least for ssh, I'm not sure about dstore)
I think this is something we should discuss at our F2F in Chicago.
We should invent a different kind of path mapping, and perhaps store the RSE TempFiles outside Eclipse projects (bug 158770).
Our approach for things like invalid characters (for windows) has been to store the temp file path using the escaped characters. For handling stuff like files of the same name but different case we could do something similar (i.e. map the remote name to something different locally). One problem we face with both the handling of invalid characters as well as case via name mapping, is that we can't control the name the eclipse editor shows. When a file is opened in an editor, the FileEditorInput displays the name of the local file in the tab of the editor pane (and the full path in the tooltip). For example, if we had a scheme like A.txt -> <upper>a</upper>.txt a.txt -> <lower>a</lower>.txt We would stil end up seeing: "<upper>a</upper>.txt" in the editor tab when viewing A.txt. Another scheme could be like this: A.txt -> .../upper/a.txt a.txt -> .../lower/a.txt With this scheme, we end up seeing: "a.txt" in the editor tab but ".../upper/a.txt" in the tooltip. Without control over the editors, I'm not sure how we can win with this one.
What about an approach similar to how Windows maps file names to 8.3 names: a.txt --> a.txt A.txt --> a~1.txt A.TXT --> a~2.txt i.e. any file or folder name that cannot be expressed directly in the file system for any reason is mapped to filename + some random postfix. A mapping table keeps track of the mappings between the abbreviated file names to the real (remote) names. Every directory in the RemoteSystemsTempFiles area could have one file (e.g. .mappings) that has the mappings.
With respect to uppercase / lowercase mappings specifically, another approach could be like what we're already doing for connection alias names in the RemoteSystemsConnections area: Given a file name like abcdeFg.Txt use a bitmask to specify which character position should be uppercase. In the example, it is the 6th and 9th characer, so 2^5 + 2^8 = 32 + 256 = 288 so the file name would be abcdefg.txt_288 i.e. append the bitmask as postfix. DaveD knows more about that mapping code. Naturally, the mapping gets problematic with file names longer than 32 characters. And, invalid characters would still need to be escaped.
(In reply to comment #8) > What about an approach similar to how Windows maps file names to 8.3 names: > a.txt --> a.txt > A.txt --> a~1.txt > A.TXT --> a~2.txt > i.e. any file or folder name that cannot be expressed directly in the file > system for any reason is mapped to filename + some random postfix. A mapping > table keeps track of the mappings between the abbreviated file names to the > real (remote) names. Every directory in the RemoteSystemsTempFiles area could > have one file (e.g. .mappings) that has the mappings. My point was that regardless of how we map the files, we're going to get editors that show the wrong thing in the name tab.
Right. Only a special kind of EFS provider could probably solve that, at the risk of not working in editors that do not support EFS properly. Therefore, my proposal was to try and keep the mapped file name as close to the original file name as possible; users would still know what file was being edited, even if the file name does not exactly match the real name (it would still sort of match).
This is a nasty one that I'd love to see addressed in 3.1 -- we might need to create a plan item for all cache related issues to address.
To weigh in, I personally think it's much less important to try and get the editor to show the correct file name at the top than it is to avoid data corruption. As long as I can click on a file in the Explorer and that file opens up in the editor, I don't care much if it has some funky filename listed at the top.
Bulk moving 3.2.x bugs to 3.3
Bulk moving 3.3 deferred items to 3.3.1
Very related: #276897
