[ nedit-Bugs-1616278 ] Windows/Cygwin file name compatibility

[SourceForge.net]

Bugs item #1616278, was opened at 2006-12-15 11:37
Message generated for change (Comment added) made by ajbj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=111005&aid=1616278&group_id=11005

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joerg Fischer (jf505)
Assigned to: Nobody/Anonymous (nobody)
Summary: Windows/Cygwin file name compatibility

Initial Comment:
When running on MS Windows (using Cygwin), NEdit should not distinguish between cases in filenames, otherwise it opens the same file twice, eg as file.txt and File.TXT.

Notice that the hack attached is only meant as demonstration and also is not complete.  It is still possible to open the same file twice because of Cygwin mount points, i.e., if the Cygwin root is on say C:\cygwin, then /home/user/file.txt points to the same file as /cygdrive/c/cygwin/home/user/file.txt.

(Notice that with the /cygdrive/ prefix you can reach all areas of all the drives under MS Windows regardless of mount points.)

----------------------------------------------------------------------

Comment By: Tony Balinski (ajbj)
Date: 2007-03-02 00:35

Message:
Logged In: YES 
user_id=618141
Originator: NO

Actually, if you use Windows with nedit, this can be a real pain. Edit
something in nedit, compile it in Visual Studio, copy the error message
back into nedit to use a macro to jump to the lines in error... Well thank
you Microsoft: all paths in the error messages are set to lower case: you
can open them, but if already opened, this won't be recognised and you end
up with the same file opened twice in two different, independent text
buffers. It also pollutes the "Open previous" file history with duplicates
different only in case.

----------------------------------------------------------------------

Comment By: Thorsten Haude (yooden)
Date: 2007-01-04 00:23

Message:
Logged In: YES 
user_id=119143
Originator: NO

- Point taken, I don't even know how NTFS handles case.
- I'm not against it, I just suggested that one should handle this problem
along with VMS wherever useful.

----------------------------------------------------------------------

Comment By: Joerg Fischer (jf505)
Date: 2007-01-03 22:05

Message:
Logged In: YES 
user_id=918104
Originator: YES

Just for the record, the report is not about Windows support (my fault),
but of course for proper support of case insensitive file systems. You
know, Unix or Linux is not tied to a particular system, one can mount many
file systems (once kernel support is there).

I think Tony is right. NEdit should get the file names as they are in the
directory entries. That is, file names on the command line should be
replaced with the respecive directory entries, which is superfluous (but
not wrong) on case sensitive file system and would be good for the case
insensitive ones.

----------------------------------------------------------------------

Comment By: Thorsten Haude (yooden)
Date: 2007-01-03 16:06

Message:
Logged In: YES 
user_id=119143
Originator: NO

I don't see the pressing need to support Windows idiosyncracies, I
wouldn't mind a good patch for this. If applicable it should be merged with
any similar VMS code, but I think VMS does use a more intelligent approach
by not allowing lower case in the first place.

Alternatively, have NEdit look at inodes on every new file.

----------------------------------------------------------------------

Comment By: Tony Balinski (ajbj)
Date: 2006-12-18 11:11

Message:
Logged In: YES 
user_id=618141
Originator: NO

Good idea. I think there might be some NT stuff (Cygwin stuff too?)
telling you whether the file system has case significance or not (imagine
going to a Samba share from your Windows box). Hmmm. In fact, it would be
nice to have NEdit respect the case of the file path elements as they
appear in the directory entries rather than as as supplied by the user, or
converted arbitrarily to upper or lower case.

Isn't VMS also case insensitive, or has that changed since I last used it
(circa 1999)?

BTW there's the problem with spaces in paths/names - I had a crack at a
fix for the bug I entered as #1565125 - No spaces in paths for "Open
Selected", which also probably needs some work.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=111005&aid=1616278&group_id=11005