This is the mail archive of the cygwin-talk mailing list for the cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Cannot write files if they are hidden


----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....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]