RE: 3 bugs

RE: 3 bugs

[John Wiersba]

> -----Original Message-----
> From: Thomas.Wolff@icn.siemens.de [ mailto:Thomas.Wolff@icn.siemens.de ]
> Sent: Friday, April 14, 2000 9:26 AM
> To: cygwin@sourceware.cygnus.com
> Subject: 3 bugs
>
> My program could create a file "xy." (with a final dot) in the cygwin 
> environment using a link() call, but I could not manage by any means 
> to use, remove, or rename that file afterwards.

I encounter a similar problem.  Apparently, files with a trailing "." are
mapped to files without any extension.

$ touch ab. cd.
$ ls -l
-rw-r--r--   1 administ JRW             0 Apr 17 18:21 ab
-rw-r--r--   1 administ JRW             0 Apr 17 18:21 cd
$ rm ab.
$ ls -l
-rw-r--r--   1 administ JRW             0 Apr 17 18:21 cd
$ rm cd
$ ls -l
total 0


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: 3 bugs

[DJ Delorie]

> I encounter a similar problem.  Apparently, files with a trailing "." are
> mapped to files without any extension.

It sounds like this is a "feature" of the Win32 file system, in that
it doesn't *quite* preserve the file name correctly.  If so, there's
not much we can do about it.  Except, perhaps, to MIME encode the
problem file names :-(

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: 3 bugs

[Martin Heller]

DJ Delorie wrote:
> It sounds like this is a "feature" of the Win32 file system, in that
> it doesn't *quite* preserve the file name correctly.  If so, there's
> not much we can do about it.  Except, perhaps, to MIME encode the
> problem file names :-(
It's a "feature" of the - in this respect absolutely brain damaged -
NT/Win32 subsystem  file naming/handling: 
NTFS knows the difference between "xy." and "xy" , but the Win32 layer 
"erases" this knowledge !
Getting this NTFS capability back under Win32 is not a trivial task,
perhaps not doable without writing a kernel subsystem .

MARTIN

P.S.: The Interix Posix subsystem knows the difference on NTFS

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: 3 bugs

[DJ Delorie]

> Getting this NTFS capability back under Win32 is not a trivial task,
> perhaps not doable without writing a kernel subsystem .
> P.S.: The Interix Posix subsystem knows the difference on NTFS

We've talked about bypassing the win32 file system layer for other
things, but decided against it because it lets you create files that
other standard win32 programs (like explorer) can't deal with.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: 3 bugs

[Paul Sokolovsky]

Hello DJ,

DJ Delorie <dj@delorie.com> wrote:

DD> It sounds like this is a "feature" of the Win32 file system, in that
DD> it doesn't *quite* preserve the file name correctly.  If so, there's
DD> not much we can do about it.  Except, perhaps, to MIME encode the
DD> problem file names :-(

    Cool idea! ;-) But what about mere urlencoding filenames? Here
problem arises: what to do with '%' itself. At least 3 following
choices are available:

1. Be formally correct: replace '%' with '%25'. But this will lead to
incompatibility with native apps. E.g.: script, native apps delivers
filename and cygwin apps tries to open it.

2. Don't touch '%' at all.

3. Oversafing: try filename with '%' urlencoded, if it fails, try
original.

         For me, 1 is not acceptable, and 3 way to complicated. So,
I've chosen 2 - I don't know about any app using % in filenames
consistently, so to come upon filename with '%' followed by two uppercase
hex digits is very low probability for me.



--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: 3 bugs

[John Wiersba]

> -----Original Message-----
> From: Heribert Dahms [ mailto:heribert_dahms@icon-gmbh.de ]
> 
> since ? ist the wildcard for a single character, try
> to protect it with a backslash escape or quote all.

Yes, that works much better:

   rm '//?/d:/dir1/dir2/x.'   or
   rm '\\?\d:\dir1\dir2\x.'

-- John


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: 3 bugs

[Heribert Dahms]

Hi John,

since ? ist the wildcard for a single character, try
to protect it with a backslash escape or quote all.

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	John Wiersba [SMTP:John.Wiersba@medstat.com]
> Sent:	Wednesday, April 19, 2000 20:20
> To:	'Larry Hall (RFK Partners, Inc)'; Thomas.Wolff@icn.siemens.de;
> benny@crocodial.de; cygwin@sourceware.cygnus.com
> Subject:	RE: 3 bugs
> 
> [Heribert]  [snip]
> 
> OK, I retract my statement.  I tried it again.  It does work, with
> this
> caveat (at least on my machine):  that it probes all my drives and
> perhaps
> the network first, before removing the file.  I believe that is
> because of
> the // syntax.  When I originally tried it, I killed it when I saw it
> was
> probing my floppy drive, so I didn't give it a chance to finish.
> 


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: 3 bugs

[John Wiersba]

> -----Original Message-----
> From: Larry Hall (RFK Partners, Inc) [ mailto:lhall@rfk.com ]
> 
> At 01:59 PM 4/19/00, John Wiersba wrote:
> > > -----Original Message-----
> > > From: Larry Hall (RFK Partners, Inc) [ mailto:lhall@rfk.com ]
> > > 
> > > At 07:47 AM 4/19/00, Thomas.Wolff@icn.siemens.de wrote:
> > > >: For any file that Explorer can't deal with, try using this 
> > > syntax in
> > > >: cmd.exe:
> > > >: 
> > > >:   del \\?\c:\tmp\xxxxx
> > > >
> > > >Thanks a lot. Finally got rid of those files.
> > > >Works under cygwin bash as well (rm \\\\?\\c:\\temp\\xy.)
> > > 
> > > So doesn't rm //?/c:/temp/xy.
> >
> >Nope.
> 
>  From bash it works, at least for me it does...

OK, I retract my statement.  I tried it again.  It does work, with this
caveat (at least on my machine):  that it probes all my drives and perhaps
the network first, before removing the file.  I believe that is because of
the // syntax.  When I originally tried it, I killed it when I saw it was
probing my floppy drive, so I didn't give it a chance to finish.

-- John


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: 3 bugs

[Larry Hall (RFK Partners, Inc)]

At 01:59 PM 4/19/00, John Wiersba wrote:
> > -----Original Message-----
> > From: Larry Hall (RFK Partners, Inc) [ mailto:lhall@rfk.com ]
> > 
> > At 07:47 AM 4/19/00, Thomas.Wolff@icn.siemens.de wrote:
> > >: For any file that Explorer can't deal with, try using this 
> > syntax in
> > >: cmd.exe:
> > >: 
> > >:   del \\?\c:\tmp\xxxxx
> > >
> > >Thanks a lot. Finally got rid of those files.
> > >Works under cygwin bash as well (rm \\\\?\\c:\\temp\\xy.)
> > 
> > So doesn't rm //?/c:/temp/xy.
>
>Nope.

 From bash it works, at least for me it does...


Larry



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: 3 bugs

[John Wiersba]

> -----Original Message-----
> From: Larry Hall (RFK Partners, Inc) [ mailto:lhall@rfk.com ]
> 
> At 07:47 AM 4/19/00, Thomas.Wolff@icn.siemens.de wrote:
> >: For any file that Explorer can't deal with, try using this 
> syntax in
> >: cmd.exe:
> >: 
> >:   del \\?\c:\tmp\xxxxx
> >
> >Thanks a lot. Finally got rid of those files.
> >Works under cygwin bash as well (rm \\\\?\\c:\\temp\\xy.)
> 
> So doesn't rm //?/c:/temp/xy.

Nope.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: 3 bugs

[Larry Hall (RFK Partners, Inc)]

At 07:47 AM 4/19/00, Thomas.Wolff@icn.siemens.de wrote:
>: For any file that Explorer can't deal with, try using this syntax in
>: cmd.exe:
>: 
>:   del \\?\c:\tmp\xxxxx
>
>Thanks a lot. Finally got rid of those files.
>Works under cygwin bash as well (rm \\\\?\\c:\\temp\\xy.)



So doesn't rm //?/c:/temp/xy.



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX
                                        (508) 560-1285 - cell phone



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: 3 bugs

[Benjamin Riefenstahl]

Hi Paul,


Paul Sokolovsky wrote:
>     Nice feature and fully answers original question. I'll try to
> comment why it's hardly usable to make cygwin less fastidious about
> filenames:

Making cygwin use this syntax in all cases is not something that would
be usefull for me.  I need my files to be accessible with regular
Windows tools without special syntax tricks.  Otherwise I could just
switch to Linux and forget about all those compatibility issues once and
for all.

So I was only suggesting this as a solution for people that somehow have
managed to create those files and want to get rid of them.

> - it works only with nt, not 9x

I don't remember if there was a solution for Win9x, you may want to
search the list archives.  IIRC the discussion was about files called
"aux" then.

> - it requires full path

Not a problem for me (s.a.).

> - it doesn't allow too much, e.g. it lets that dot at the end, but
> not filename containing ':' or '*' .

Does the file system driver allow you to create these kind of files
somehow like it does for "t." or "aux.c"?  I would doubt that.


so long, benny
======================================
Benjamin Riefenstahl (benny@crocodial.de)
ISION Internet AG
Ruhrstr. 61, D-22761 Hamburg, Germany

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: 3 bugs

[John Wiersba]

It worked for me too:  rm '\\?\c:\temp\xy.'

Thanks!  But one question: why?

-- John

> -----Original Message-----
> From: Thomas.Wolff@icn.siemens.de [ mailto:Thomas.Wolff@icn.siemens.de ]
> Sent: Wednesday, April 19, 2000 7:47 AM
> To: benny@crocodial.de; cygwin@sourceware.cygnus.com
> Cc: John.Wiersba@medstat.com; Thomas.Wolff@icn.siemens.de
> Subject: Re: 3 bugs
> 
> 
> : For any file that Explorer can't deal with, try using this syntax in
> : cmd.exe:
> : 
> :   del \\?\c:\tmp\xxxxx
> 
> Thanks a lot. Finally got rid of those files.
> Works under cygwin bash as well (rm \\\\?\\c:\\temp\\xy.)
> 
> Regards,
> Thomas
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: 3 bugs

[Thomas.Wolff]

: For any file that Explorer can't deal with, try using this syntax in
: cmd.exe:
: 
:   del \\?\c:\tmp\xxxxx

Thanks a lot. Finally got rid of those files.
Works under cygwin bash as well (rm \\\\?\\c:\\temp\\xy.)

Regards,
Thomas

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: 3 bugs

[Benjamin Riefenstahl]

Hi all,

For any file that Explorer can't deal with, try using this syntax in
cmd.exe:

  del \\?\c:\tmp\xxxxx

replace c:\tmp\ with the actual path using DOS style (backslashes) and
replace xxxxx with the actual underlying file name, like e.g. "t." .

The Prefix "\\?\" tells NT to do no parsing at all on the file name but
pass it to the file system driver unchanged.

This trick should probably go into the FAQ, we had a similar problem
before already.

so long, benny
======================================
Benjamin Riefenstahl (benny@crocodial.de)
ISION Internet AG
Ruhrstr. 61, D-22761 Hamburg, Germany

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: 3 bugs

[John Wiersba]

> -----Original Message-----
> From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> Sent: Tuesday, April 18, 2000 1:17 PM
> 
> Have you tried quoting techniques?
> 
> rm b\.
> rm "b."
> rm "b\."

Well, sort of.  

$ ls -li
total 0
20061687 -rw-r--r--   1 administ JRW             0 Apr 18 14:04 b
20061687 -rw-r--r--   1 administ JRW             0 Apr 18 14:04 b.
$ rm b
$ ls -li
ls: b.: No such file or directory
total 0
$ touch b
$ ls -li
total 0
20389367 -rw-r--r--   1 administ JRW             0 Apr 18 14:14 b
20389367 -rw-r--r--   1 administ JRW             0 Apr 18 14:14 b.

Note the different "inode" numbers.  Apparently, there is a directory entry
for b. which is pathologically linked to the name b (no dot).

-- John Wiersba

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: 3 bugs

[Earnie Boyd]

Have you tried quoting techniques?

rm b\.
rm "b."
rm "b\."

Earnie.

--- John Wiersba <John.Wiersba@medstat.com> wrote:
> Now, you've done it.  It's like a virus!  I tried testing your bug and now
> *I* have a file called b. which I can't get rid of.  Explorer compains:
> Cannot delete b:  Cannot find the specified file.
> 
> -- John
> 
> > -----Original Message-----
> > From: Thomas.Wolff@icn.siemens.de [ mailto:Thomas.Wolff@icn.siemens.de ]
> > Sent: Tuesday, April 18, 2000 11:15 AM
> > To: cygwin@sourceware.cygnus.com
> > Subject: Re: 3 bugs
> > 
> > 
> > On my bug report
> > > My program could create a file "xy." (with a final dot) in 
> > the cygwin 
> > > environment using a link() call, but I could not manage by 
> > any means 
> > > to use, remove, or rename that file afterwards.
> > there were several replies.
> > 
> > : I encounter a similar problem.  Apparently, files with a 
> > trailing "." are
> > : mapped to files without any extension.
> > : 
> > : $ touch ab.
> > : $ ls
> > : ab
> > : $ rm ab.
> > : $ ls
> > : $ 
> > That's well-known DOS-like behaviour. Not the bug I 
> > described. See that 
> > the file created was named "ab" without a dot.
> > 
> > The problem is rather the following:
> > $ touch ab
> > $ ln ab xy.
> > $ ls
> > ab      xy.
> > $ rm ab
> > $ ls
> > xy.
> > $ rm xy.
> > rm: xy.: No such file or directory
> > $ rm xy
> > rm: xy: No such file or directory
> > $ ls
> > xy.
> > $ grrr
> > 
> > 
> > : It sounds like this is a "feature" of the Win32 file system, in that
> > : it doesn't *quite* preserve the file name correctly.  If so, there's
> > : not much we can do about it.  Except, perhaps, to MIME encode the
> > : problem file names :-(
> > The issue is not one of missing filename preservation either, 
> > rather on 
> > the contrary.
> > 
> > : DJ Delorie wrote:
> > : > It sounds like this is a "feature" of the Win32 file 
> > system, in that
> > : > it doesn't *quite* preserve the file name correctly.  If 
> > so, there's
> > : > not much we can do about it.  Except, perhaps, to MIME encode the
> > : > problem file names :-(
> > : It's a "feature" of the - in this respect absolutely brain damaged -
> > : NT/Win32 subsystem  file naming/handling: 
> > : NTFS knows the difference between "xy." and "xy" , but the 
> > Win32 layer 
> > : "erases" this knowledge !
> > : Getting this NTFS capability back under Win32 is not a trivial task,
> > : perhaps not doable without writing a kernel subsystem .
> > Don't know if that's the situation. I tried every tool I have (Norton 
> > commander clones etc.)
> > 
> > : > Getting this NTFS capability back under Win32 is not a 
> > trivial task,
> > : > perhaps not doable without writing a kernel subsystem .
> > : > P.S.: The Interix Posix subsystem knows the difference on NTFS
> > : We've talked about bypassing the win32 file system layer for other
> > : things, but decided against it because it lets you create files that
> > : other standard win32 programs (like explorer) can't deal with.
> > Which one can?
> > 
> > Regards,
> > Thomas Wolff
> > 
> > --
> > Want to unsubscribe from this list?
> > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> > 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 
> 

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: 3 bugs

[John Wiersba]

Now, you've done it.  It's like a virus!  I tried testing your bug and now
*I* have a file called b. which I can't get rid of.  Explorer compains:
Cannot delete b:  Cannot find the specified file.

-- John

> -----Original Message-----
> From: Thomas.Wolff@icn.siemens.de [ mailto:Thomas.Wolff@icn.siemens.de ]
> Sent: Tuesday, April 18, 2000 11:15 AM
> To: cygwin@sourceware.cygnus.com
> Subject: Re: 3 bugs
> 
> 
> On my bug report
> > My program could create a file "xy." (with a final dot) in 
> the cygwin 
> > environment using a link() call, but I could not manage by 
> any means 
> > to use, remove, or rename that file afterwards.
> there were several replies.
> 
> : I encounter a similar problem.  Apparently, files with a 
> trailing "." are
> : mapped to files without any extension.
> : 
> : $ touch ab.
> : $ ls
> : ab
> : $ rm ab.
> : $ ls
> : $ 
> That's well-known DOS-like behaviour. Not the bug I 
> described. See that 
> the file created was named "ab" without a dot.
> 
> The problem is rather the following:
> $ touch ab
> $ ln ab xy.
> $ ls
> ab      xy.
> $ rm ab
> $ ls
> xy.
> $ rm xy.
> rm: xy.: No such file or directory
> $ rm xy
> rm: xy: No such file or directory
> $ ls
> xy.
> $ grrr
> 
> 
> : It sounds like this is a "feature" of the Win32 file system, in that
> : it doesn't *quite* preserve the file name correctly.  If so, there's
> : not much we can do about it.  Except, perhaps, to MIME encode the
> : problem file names :-(
> The issue is not one of missing filename preservation either, 
> rather on 
> the contrary.
> 
> : DJ Delorie wrote:
> : > It sounds like this is a "feature" of the Win32 file 
> system, in that
> : > it doesn't *quite* preserve the file name correctly.  If 
> so, there's
> : > not much we can do about it.  Except, perhaps, to MIME encode the
> : > problem file names :-(
> : It's a "feature" of the - in this respect absolutely brain damaged -
> : NT/Win32 subsystem  file naming/handling: 
> : NTFS knows the difference between "xy." and "xy" , but the 
> Win32 layer 
> : "erases" this knowledge !
> : Getting this NTFS capability back under Win32 is not a trivial task,
> : perhaps not doable without writing a kernel subsystem .
> Don't know if that's the situation. I tried every tool I have (Norton 
> commander clones etc.)
> 
> : > Getting this NTFS capability back under Win32 is not a 
> trivial task,
> : > perhaps not doable without writing a kernel subsystem .
> : > P.S.: The Interix Posix subsystem knows the difference on NTFS
> : We've talked about bypassing the win32 file system layer for other
> : things, but decided against it because it lets you create files that
> : other standard win32 programs (like explorer) can't deal with.
> Which one can?
> 
> Regards,
> Thomas Wolff
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: 3 bugs

[Thomas.Wolff]

On my bug report
> My program could create a file "xy." (with a final dot) in the cygwin 
> environment using a link() call, but I could not manage by any means 
> to use, remove, or rename that file afterwards.
there were several replies.

: I encounter a similar problem.  Apparently, files with a trailing "." are
: mapped to files without any extension.
: 
: $ touch ab.
: $ ls
: ab
: $ rm ab.
: $ ls
: $ 
That's well-known DOS-like behaviour. Not the bug I described. See that 
the file created was named "ab" without a dot.

The problem is rather the following:
$ touch ab
$ ln ab xy.
$ ls
ab      xy.
$ rm ab
$ ls
xy.
$ rm xy.
rm: xy.: No such file or directory
$ rm xy
rm: xy: No such file or directory
$ ls
xy.
$ grrr


: It sounds like this is a "feature" of the Win32 file system, in that
: it doesn't *quite* preserve the file name correctly.  If so, there's
: not much we can do about it.  Except, perhaps, to MIME encode the
: problem file names :-(
The issue is not one of missing filename preservation either, rather on 
the contrary.

: DJ Delorie wrote:
: > It sounds like this is a "feature" of the Win32 file system, in that
: > it doesn't *quite* preserve the file name correctly.  If so, there's
: > not much we can do about it.  Except, perhaps, to MIME encode the
: > problem file names :-(
: It's a "feature" of the - in this respect absolutely brain damaged -
: NT/Win32 subsystem  file naming/handling: 
: NTFS knows the difference between "xy." and "xy" , but the Win32 layer 
: "erases" this knowledge !
: Getting this NTFS capability back under Win32 is not a trivial task,
: perhaps not doable without writing a kernel subsystem .
Don't know if that's the situation. I tried every tool I have (Norton 
commander clones etc.)

: > Getting this NTFS capability back under Win32 is not a trivial task,
: > perhaps not doable without writing a kernel subsystem .
: > P.S.: The Interix Posix subsystem knows the difference on NTFS
: We've talked about bypassing the win32 file system layer for other
: things, but decided against it because it lets you create files that
: other standard win32 programs (like explorer) can't deal with.
Which one can?

Regards,
Thomas Wolff

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

3 bugs

[Thomas.Wolff]

The middle key of the right keypad (labelled "5") does not deliver an 
escape sequence to the application as it should in function key mode 
(also known as keypad mode).

When I enter a ^C during an invocation of select(), it seems to interrupt 
the call although the program disabled the SIGINTR-^C relationship by 
the usual means (which works under Unix) and ^C as a normal character 
works at other times in the same program under cygwin as well (this is 
in raw input mode, for use in an editor).

My program could create a file "xy." (with a final dot) in the cygwin 
environment using a link() call, but I could not manage by any means 
to use, remove, or rename that file afterwards.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com