Re: Cannot write files if they are hidden

[Cliff Hones <cliff at hones dot org dot uk>]

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