<http://cygwin.com/acronyms/#TOFU>.  Reformatted.

Also, <http://cygwin.com/acronyms/#PCYMTNQREAIYR>.  Don't feed the spammers.
I've removed raw email addressed you quoted from my response.

Long, Phillip GOSS wrote:
Larry Hall wrote:
Long, Phillip GOSS wrote:
Hello!

On 06-oct-2006 22:44, I upgraded my Cygwin installation from
mirrors.kernel.org.  There are two Windows fileservers to which I have
access, and which I have mounted, that now show up colored yellow on
black, and apparently _are_ being treated as character special
devices.
At first I thought it was 'bash' acting up, because when I used
tab-completion, the `bash' shell died, and the parent process (`rxvt,'
in this case) died because the `bash' shell exited.  It turned out to
also happen with _any_ `bash' shell running in _any_ window (`rxvt,'
Windows CMD console, `rxvt' and `xterm' under `XWin,' etc.), and there
are also similar problems when running `cp,' `ls,' and `mv,' so I
suspect that this may be an interaction between the fileservers and an
underlying DLL.

There are only two fileservers which exhibit this behavior; there are
about three others which do not show up as character devices and for
which tab-completion (and everything else) works.  When I `cd' to a
directory on one of the affected servers (_not_ using
tab-completion!),
I can do an `ls,' but the dates show up 14-jan-1979 (see attached
`ls-al[ctu]r.lis' and `cmd-dir.lis' files), as if the binary timestamp
were 0, or close to it; `ls' returns no data and an exit status of 0
if
it is run on a directory on the affected server with $PWD on another
filesystem.  I also found that if I am examining a file using `less'
and
shell out with the `!' command to run an `ls' command on one of these
fileservers, tab-completion (using lesskey?) fails, but does not cause
less to die, nor does the command I am typing die (I just get a <BEL>
on
the terminal).  I can `cp' and `mv' files to such a fileserver, but
not
re-direct output (a zero-length file is created when I redirect
output).
Finally, this is only a problem on the fileservers, not on my local
machine (even on a USB2.0-connected 60GiB Iomega hard drive).

I am running on a WinXP Professional platform; I believe, but am not
sure, that this is also the case for the fileservers.  The versions of
the `bash,' `cyg*,' and `less' packages is in the attached file
`setup.ini.extract.'

I suppose I could go back to the previous version, but there were some
issues with that as well, and I would rather fix this instead.  I
haven't found anything in the archives, but I may have missed what I
need; I apologize for taking up your time if I have dropped the ball.

                                        Thx, Phil the Old Coder
<< File: ls-alur.lis >> << File: ls-alcr.lis >> << File: ls-altr.lis >> << File: cmd-dir.lis >> << File: setup.ini.extract >>


This looks like more of a permissions problem of some kind.  What does
'getfacl' or 'cacls' have to say about any of these files/directories?
What's the file system here?  Knowing what O/S and sharing protocol
would
be helpful.  And, in general:

Problem reports:       http://cygwin.com/problems.html

'cygcheck' information here is really critical to start.

> I do not know _which_ Windows OS the fileservers are running (I only
> have user access, and no physical access, to them), but it _is_ NTFS
> that is used.  Here is the output of `getfacl' and `cacls' on a
> directory which works:
>    # file: /s/DUR-SERVICE/Service-Open-Items
>    # owner: LongPhil
>    # group: Domain Users
>    user::rwx
>    group::r-x
>    other:r-x
>    mask:rwx
>    s:\DUR-SERVICE\Service-Open-Items
> GOSS\GRP-DUR-L-DUR-SERVICE_SERVICE-OPEN-ITEMS (RO):(OI)(CI)R
>    
> GOSS\GRP-DUR-L-DUR-SERVICE_SERVICE-OPEN-ITEMS (RW):(OI)(CI)C
>    
> GOSS\ADM-DOV-AdminFileData:(OI)(CI)F
>    
> BUILTIN\Administrators:(OI)(CI)F
>                                      CREATOR OWNER:(OI)(CI)(IO)F
>                                      NT AUTHORITY\SYSTEM:(OI)(CI)F
> Here is the output of `getfacl' and `cacls' on a directory which does
> NOT work:
>       # file: /r/user/LongPhil/Service/qnx/4/logs/unitedlitho
>       # owner: LongPhil
>       # group: Domain Users
>
>       r:\user\LongPhil\Service\qnx\4\logs\unitedlitho <Account Domain
> not found>(OI)(CI)F
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Bingo!


>                                                       Everyone:(OI)(CI)R
>
>
> GOSS\dur.docman:(OI)(CI)F
>
> GOSS\LongPhil:(OI)(CI)C
>
> Finally, I have attached a `cygcheck -c' output file; as U can see,
> there are three packages that are not `OK:'
>       Cygwin Package Information
>       Package                  Version            Status
>       hicolor-icon-theme       0.5-1              Incomplete
>       lyx                      1.4.3-4            Incomplete
>       tetex-bin                3.0.0-3            Incomplete


Actually, I was looking for 'cygcheck -srv' output but I think we found
the problem without it.  As for the above three packages, yes, you should
reinstall them if you want to use them.


> As far as I can tell, nothing changed on the fileservers; IT usually
> changes _everything_ at once, and usually only in tiny increments.  Our
> domain users list gets changed fairly regularly, however; could having
> an out-of-date /etc/passwd and /etc/group make a difference?


Yes, it does.  Please regenerate them using the '-l' and '-d' switches.
If that's not enough to make the problem go away, you may need to look
at specifying your domain server to the '-d' flag to get things to work.

--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

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

Reply via email to