RE: Cannot write files if they are hidden

RE: Cannot write files if they are hidden

[Dave Korn]

----Original Message----
>From: Cliff Hones
>Sent: 22 July 2005 17:43

[ Bock-bock b'gawwwk! ]

> Well, aside from whether that's sensible, Cygwin doesn't actually achieve
> this as far as the user interface is concerned.

  Well, it does as far as your original report was concerned (see the
subject line of this thread if you want to remind yourself what you
originally reported....)

----------------------------in cmd.exe----------------------------
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\dk>echo "hello world" > aaa

C:\Documents and Settings\dk>attrib +h aaa

C:\Documents and Settings\dk>echo "hello world" > aaa
Access is denied.
--------------------------in cygwin bash--------------------------
dk@mace ~> echo "hello world" > bbb
dk@mace ~> cmd /c attrib +h bbb
dk@mace ~> echo "hello world" > bbb
bash: bbb: Permission denied
dk@mace ~>
------------------------------------------------------------------

> Windows hidden files are listed by "ls" (but aren't by windows "dir").

  Yes they are:

----------------------------in cmd.exe----------------------------
C:\Documents and Settings\dk>dir /ah aaa
 Volume in drive C has no label.
 Volume Serial Number is 942E-907E

 Directory of C:\Documents and Settings\dk

22/07/2005  18:27                16 aaa
               1 File(s)             16 bytes
               0 Dir(s)  55,361,261,568 bytes free
------------------------------------------------------------------

  Of course, "dir" filters lots of files by default, and you have to add
"/ah" to prevent it.  Much like how "ls" filters out files beginning with
'.' by default, and you have to add "-a" to prevent it...

> Under Windows you can read and append, but not replace - this is same as
> Cygwin. 

  That's good.

> But Windows "del <hiddenfile>" reports file not found, 

  Perhaps you should read the help instructions for del?

----------------------------in cmd.exe----------------------------
C:\Documents and Settings\dk>echo "hello" >aaa

C:\Documents and Settings\dk>attrib +r aaa

C:\Documents and Settings\dk>del /f aaa

C:\Documents and Settings\dk>
------------------------------------------------------------------

> while Cygwin "rm" does delete the file.

  Hmmm, this one is weird.  Sometimes rm does, sometimes it doesn't.  While
investigating with "rm -i", I sometimes saw "Remove write-protected file?",
and at other "Remove regular file"; but I couldn't reproduce it, and there
were too many varying factors for me to try systematically: whether the file
is empty or has contents makes a difference to how it behaves, whether it
was initially created by 'doze or Cygwin makes a difference, and possibly
other things too.

  However, in general, Cygwin is a POSIX emulation layer, not a windows
emulation layer.  So there's no reason why "ls" and "dir" should act the
same as each other, nor need "rm" and "del" be consistent.

> Would I be right in guessing there is no logic in Cygwin to specifically
> deal with the Windows "H" attribute, and what we are seeing is the result
> of the quirky Microsoft API behaviour?

  That's not _your_ guess, *I* said that!  Admittedly I only _implied_ it by
saying that the intended behaviour was "the same as" 'doze, but there ya
go.....


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: Cannot write files if they are hidden

[Dave Korn]

----Original Message----
>From: Cliff Hones
>Sent: 26 July 2005 18:04

> On Friday 22nd July Dave Korn wrote:
> 
>>> From: Cliff Hones
>>> Sent: 22 July 2005 17:43
>> 
>> [ Bock-bock b'gawwwk! ]
>> 
>>> Well, aside from whether that's sensible, Cygwin doesn't actually
>>> achieve this as far as the user interface is concerned.
>> 
>>   Well, it does as far as your original report was concerned (see the
>> subject line of this thread if you want to remind yourself what you
>> originally reported....)
> 
> Apologies for the late reply - only just spotted you'd let the chickens
> out 


   WHO LET THE CHICKENS OUT?   (Bock, Bock, Bock Bock)

   WHO LET THE CHICKENS OUT?   (Bock, Bock, Bock Bock)

   WHO LET THE CHICKENS OUT?   (Bock, Bock, Bock Bock)


> on this.
> 
> To put the record straight, I was not the OP; that was Bryan Thrall, 

  You mean you just insinuated yourself slyly right in between the two of
us?  That's disgusting!  What are you doing wearing his clothes?!

> one to write to a hidden file, it seems perfectly valid to point out that
> Cygwin apps do not in general exhibit the same behaviour as Windows apps
> when applied to hidden files.  I've just checked again - notepad will
> write to a 
> hidden file (and keep it hidden), but then wordpad gets "access denied" -
> so windows itself isn't exactly consistent!

  Way to undermine yourself!  Let me see if I've summarized your paragraph
correctly:

 "It seems perfectly valid" to complain that cygwin apps "do not in general
exhibit the same behaviour as windows apps" - because cygwin apps are
inconsistent, whereas windows apps, on the other hand, are inconsistent?

  Or, in other words, as I went to quite a lot of trouble to demonstrate:
cygwin apps ***DO*** exhibit ***EXACTLY*** the same behaviour as windows
apps: they _all_ behave inconsistently because the underlying OS behaves
inconsistently.

  So apart from agreeing with everything I said, you made this post exactly
_why_?

> Anyway, what I said was:
>   > Windows hidden files are listed by "ls" (but aren't by windows "dir").
>   > Under Windows you can read and append, but not replace - this is same
>   as Cygwin. > But Windows "del <hiddenfile>" reports file not found,
>   while Cygwin "rm" does > delete the file.
> 
> You seem to be disputing this, 

  Bit difficult to tell, because you've snipped everything that I actually
wrote and merely left your paraphrase of what I was saying, probably so that
you can misrepresent what I said without fear of contradiction.

> any differences you find just go to confirm windows is inconsistent. 

  That was what my post was saying.  That was why it's nothing to do with
cygwin.  That was why reporting inconsistencies between inconsistent cygwin
apps and inconsistent windows apps was such a uniquely pointless waste of
time.

>> ----------------------------in cmd.exe----------------------------
>> Microsoft Windows XP [Version 5.1.2600]
>> (C) Copyright 1985-2001 Microsoft Corp.
>> 
>> C:\Documents and Settings\dk>echo "hello world" > aaa
>> 
>> C:\Documents and Settings\dk>attrib +h aaa
>> 
>> C:\Documents and Settings\dk>echo "hello world" > aaa
>> Access is denied.
>> --------------------------in cygwin bash--------------------------
>> dk@mace ~> echo "hello world" > bbb
>> dk@mace ~> cmd /c attrib +h bbb
>> dk@mace ~> echo "hello world" > bbb
>> bash: bbb: Permission denied
>> dk@mace ~>
>> ------------------------------------------------------------------
> 
> You seem to have demonstrated the corretness of part of my 2nd sentence
> here. 

  What I was demonstrating is cygwin behaving exactly the same as 'doze, in
direct contravention of your main claim.

>>> Windows hidden files are listed by "ls" (but aren't by windows "dir").
>> 
>>   Yes they are:
> 
> What's your gripe with what I said here?  

  Your assumption that "ls" and "dir" _ought_ to behave the same in the
first place.

> I obviously meant "by default"
> (ie without explicit options requesting dir to show hidden files) -
> I'd already used that phrase "by default" in my previous posting:

  Why one earth should "ls" and "rm" have the same default options?  Why
should you expect or assume that?  And why, why, why on earth why did you
think that the difference is some kind of a fault or otherwise worth
reporting to the cygwin lists?  "Man bites dog", that's news[*].  "Different
programs behave differently" isn't.
 
>   > I'm not aware of what the intended behaviour in Cygwin is 

  See, that would have been a really good time to suddenly catch yourself,
realise what you were doing, and delete the post before you even send it.
You freely admit you're preaching from a position of ignorance?  Wow, you
really shouldn't do things like that to yourself.

> - but it
>   seems the > current behaviour is inconsistent and unexpected (at least
>   by me).  I would > have expected the hidden attribute to either be
>   ignored, or to result in > behaviour similar to Unix/Posix ".<name>"
>   files [ie not showing by default > in directory listings, but access
>   unaffected by the attribute.]  It seems that > at the moment a windows
>   hidden file is listed by "ls", can be read and appended > to, but
> cannot be replaced. 
> 
> <snipped example showing what "dir /ah" does>
> 
>>> But Windows "del <hiddenfile>" reports file not found,
>> 
>>   Perhaps you should read the help instructions for del?
> 
> Why should I do that?  

  In general?  So as to actually _know_ what you're talking about, instead
of just *guessing* about how things work, finding out it's not how you
thought, and complaining that reality has gotten it wrong.

>I'm not querying or defending what Windows "del"
> does?  I'm pointing out that windows "del" does not (consistently) behave
> th same as "rm" under Cygwin.

  Yes, you have demonstrated a remarkable aptitude for missing the point:

  WHO EVER SAID "DEL" WAS MEANT TO BEHAVE THE SAME AS "RM"?  

  NO-ONE, THAT'S WHO!

>> ----------------------------in cmd.exe----------------------------
>> C:\Documents and Settings\dk>echo "hello" >aaa
>> 
>> C:\Documents and Settings\dk>attrib +r aaa
>> 
>> C:\Documents and Settings\dk>del /f aaa
>> 
>> C:\Documents and Settings\dk>
>> ------------------------------------------------------------------
> 
> Were you having a bad day?  This is demonstrating "dir"s behaviour on
> a read-only file, not a hidden one, and also with the option "/f".  how
> does that advance the discussion?

  Hey, I got one typo, missed that I'd pressed +r instead of +h, and thought
that "/f" would remove the hidden file.  Get over it!
 
>>   That's not _your_ guess, *I* said that!  Admittedly I only _implied_
>> it by saying that the intended behaviour was "the same as" 'doze, but
>> there ya go.....
> 
> Now that's a clever way to claim credit 

  It only seems that way to someone who's unable to grasp anything that
isn't explicitly spelt out for them, but it is nonetheless the complete and
whole truth.  Sorry for being too subtle for you!

> I'm rather bored by the whole discussion - but I do like a good spar when
> I  seen to have been misquoted or misunderstood!  

  Well, you gottit!  I was trained in the battlefields of Usenet and I give
no quarter![**]

> It's obvious that since
> POSIX doesn't have anything directly corresponding to the Windows
> "hidden" attribute 

  Ok, that bit makes sense.

> that Cygwin can't get a perfect and consistent match with the POSIX
> "hidden by leading dot" semantics.  

  That bit's gibberish.  There's no such thing as "POSIX hidden by leading
dot" semantics.  That's a behaviour of "ls".  It isn't done by the
readdir(..) call hiding entries, it's done by the "ls" utility discarding
certain lines of output.  The "-a" option that makes them appear isn't
passed to the underlying syscall.  You aren't being at all clear on the
separation between operating system and application here.

> In some cases where Windows doesn't provide a good 
> match with POSIX, Cygwin jumps through hoops to try to simulate POSIX
> behaviour (eg fork()), while in others, cygwin does nothing at all (eg,
> it seems, the 
> hidden attribute) and what you get is determined by the behaviour of the
> particular Windows APIs which Cygwin happens to call.  I've no problem
> with that. 

  For once, nor do I.  That's the single clearly expressed and semantically
coherent idea you've come out with in the entire post!

> Though I'd say that if anyone were to produce a patch to make
> Cygwin's behaviour more consistent with the POSIX idea of hidden 

  Oh dear, it didn't last.  "POSIX idea of hidden"?  Your thinking is so
unclear, your use of language so imprecise in specifying what conceptual
entities you are referring to at any given time, that it's hard to reply to
you, even just for the sake of an argument.

  But hey, I've given it my best shot!

> particular to not affect the access rights - it should be welcomed.

  Nope, I shouldn't have thought so.  If someone sets the hidden flag, they
WANT the file to be hidden.  Adding code to cygwin that slows down every
file I/O ever by checking first to see if it has the hidden bit and
unsetting it if so and re-setting it after cygwin closes the file just in
order for it to not make any difference to cygwin unlike what it does on
windows doesn't sound to me like anything that would be welcomed.

  But then, I'm just completely unreasonable, as I'm sure should be clear by
now.

                      ;-P~~~~


    cheers,
      DaveK

[*] "Man bites hippo", on the other hand, wouldn't so much be 'news' as
'suicide'.
[**] Don't bother asking me for spare nickels or dimes either!
-- 
Can't think of a witty .sigline today....

Re: Cannot write files if they are hidden

[Cliff Hones]

On Friday 22nd July Dave Korn wrote:

>>From: Cliff Hones
>>Sent: 22 July 2005 17:43
> 
> [ Bock-bock b'gawwwk! ]
> 
>> Well, aside from whether that's sensible, Cygwin doesn't actually achieve
>> this as far as the user interface is concerned.
> 
>   Well, it does as far as your original report was concerned (see the
> subject line of this thread if you want to remind yourself what you
> originally reported....)

Apologies for the late reply - only just spotted you'd let the chickens out
on this.

To put the record straight, I was not the OP; that was Bryan Thrall, and he
was reporting that vi and xemacs (presumably under Cygwin) could not write
to a file with the hidden attribute.  Since notepad under Windows does allow
one to write to a hidden file, it seems perfectly valid to point out that
Cygwin apps do not in general exhibit the same behaviour as Windows apps when
applied to hidden files.  I've just checked again - notepad will write to a
hidden file (and keep it hidden), but then wordpad gets "access denied" - so
windows itself isn't exactly consistent!

Anyway, what I said was:
  > Windows hidden files are listed by "ls" (but aren't by windows "dir").
  > Under Windows you can read and append, but not replace - this is same as Cygwin.
  > But Windows "del <hiddenfile>" reports file not found, while Cygwin "rm" does
  > delete the file.

You seem to be disputing this, though as I did check it on my system before posting
any differences you find just go to confirm windows is inconsistent.

> ----------------------------in cmd.exe----------------------------
> Microsoft Windows XP [Version 5.1.2600]
> (C) Copyright 1985-2001 Microsoft Corp.
> 
> C:\Documents and Settings\dk>echo "hello world" > aaa
> 
> C:\Documents and Settings\dk>attrib +h aaa
> 
> C:\Documents and Settings\dk>echo "hello world" > aaa
> Access is denied.
> --------------------------in cygwin bash--------------------------
> dk@mace ~> echo "hello world" > bbb
> dk@mace ~> cmd /c attrib +h bbb
> dk@mace ~> echo "hello world" > bbb
> bash: bbb: Permission denied
> dk@mace ~>
> ------------------------------------------------------------------

You seem to have demonstrated the corretness of part of my 2nd sentence here.

>> Windows hidden files are listed by "ls" (but aren't by windows "dir").
> 
>   Yes they are:

What's your gripe with what I said here?  I obviously meant "by default"
(ie without explicit options requesting dir to show hidden files) -
I'd already used that phrase "by default" in my previous posting:

  > I'm not aware of what the intended behaviour in Cygwin is - but it seems the
  > current behaviour is inconsistent and unexpected (at least by me).  I would
  > have expected the hidden attribute to either be ignored, or to result in
  > behaviour similar to Unix/Posix ".<name>" files [ie not showing by default
  > in directory listings, but access unaffected by the attribute.]  It seems that
  > at the moment a windows hidden file is listed by "ls", can be read and appended
  > to, but cannot be replaced.

<snipped example showing what "dir /ah" does>

>> But Windows "del <hiddenfile>" reports file not found, 
> 
>   Perhaps you should read the help instructions for del?

Why should I do that?  I'm not querying or defending what Windows "del"
does?  I'm pointing out that windows "del" does not (consistently) behave
th same as "rm" under Cygwin.


> ----------------------------in cmd.exe----------------------------
> C:\Documents and Settings\dk>echo "hello" >aaa
> 
> C:\Documents and Settings\dk>attrib +r aaa
> 
> C:\Documents and Settings\dk>del /f aaa
> 
> C:\Documents and Settings\dk>
> ------------------------------------------------------------------

Were you having a bad day?  This is demonstrating "dir"s behaviour on
a read-only file, not a hidden one, and also with the option "/f".  how
does that advance the discussion?

>> while Cygwin "rm" does delete the file.
> 
>   Hmmm, this one is weird.  Sometimes rm does, sometimes it doesn't.  While
> investigating with "rm -i", I sometimes saw "Remove write-protected file?",
> and at other "Remove regular file"; but I couldn't reproduce it, and there
> were too many varying factors for me to try systematically: whether the file
> is empty or has contents makes a difference to how it behaves, whether it
> was initially created by 'doze or Cygwin makes a difference, and possibly
> other things too.
> 
>   However, in general, Cygwin is a POSIX emulation layer, not a windows
> emulation layer.  So there's no reason why "ls" and "dir" should act the
> same as each other, nor need "rm" and "del" be consistent.
> 
>> Would I be right in guessing there is no logic in Cygwin to specifically
>> deal with the Windows "H" attribute, and what we are seeing is the result
>> of the quirky Microsoft API behaviour?
> 
>   That's not _your_ guess, *I* said that!  Admittedly I only _implied_ it by
> saying that the intended behaviour was "the same as" 'doze, but there ya
> go.....

Now that's a clever way to claim credit :-) - have you been taking PHB lessons?
[Could be a salary boost - see http://www.marktaw.com/blog/PointyHairedBoss.html.]

I'm rather bored by the whole discussion - but I do like a good spar when I
seen to have been misquoted or misunderstood!  It's obvious that since POSIX
doesn't have anything directly corresponding to the Windows "hidden" attribute
that Cygwin can't get a perfect and consistent match with the POSIX "hidden by
leading dot" semantics.  In some cases where Windows doesn't provide a good
match with POSIX, Cygwin jumps through hoops to try to simulate POSIX behaviour
(eg fork()), while in others, cygwin does nothing at all (eg, it seems, the
hidden attribute) and what you get is determined by the behaviour of the
particular Windows APIs which Cygwin happens to call.  I've no problem with that.
Though I'd say that if anyone were to produce a patch to make Cygwin's behaviour
more consistent with the POSIX idea of hidden - in particular to not affect the
access rights - it should be welcomed.

-- Cliff