X-Spam-Check-By: sourceware.org Date: Thu, 8 Dec 2005 23:43:55 -0800 From: Yitzchak Scott-Thoennes To: Eric Blake Cc: cygwin AT cygwin DOT com Subject: Re: open() giving ENOENT when trying to create files with control chars Message-ID: <20051209074355.GC5144@efn.org> References: <120920050031 DOT 22095 DOT 4398D06400029F6F0000564F22070009530A050E040D0C079D0A AT comcast DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <120920050031.22095.4398D06400029F6F0000564F22070009530A050E040D0C079D0A@comcast.net> User-Agent: Mutt/1.4.2.1i X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Fri, Dec 09, 2005 at 12:31:32AM +0000, Eric Blake wrote: > From: Yitzchak Scott-Thoennes > > > > Moving on to another "non-portable" problem, I want to create a file > > with a space at the end of the name, but cygwin is stripping spaces. > > Despite the comment in the code, this does seem to be allowed (though > > I suspect it may be via NtCreateFile only, since windows commands > > don't seem to handle filenames with spaces at the end well). I tried > > this: > > Windows strips trailing spaces and dots (unless the file name > consists only of spaces). You need a managed mount to > preserve those; otherwise "foo ", "foo.", "foo. . . . ", "foo", > and a bunch of other spellings all refer to the same file. I attempted to indicate in the message above that I tried it and succeeded in using filenames with spaces on the end (and *different* files named the same except without the spaces). It seems this is *not* an across-the-board Windows limitation. > Unlike in the other case (non-portable characters, which POSIX > allows an implementation to reject), the stripping of trailing > '.' from filenames is a violation of POSIX, but since Windows > is the culprit, cygwin cannot avoid it (except with the overhead > of managed mounts). In the case of ., I'm not sure we would want it allowed it even if Windows made it possible; too backward incompatible with those cases where a filename is specified with a . to indicate no default extension be added (e.g. gcc foo.c -o foo.). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/