This is the mail archive of the cygwin 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: cygwin 1.7 problems: network, path, file system

> Thomas, ping?
Sorry. (Somehow I don't seem to be receiving this mailing list anymore, have to check.)

> On Jun 18 11:27, Thomas Wolff wrote:
> > Hello, I had a number of problems with cygwin 1.7:
> > 
> > 
> > ----------------------
> > Network problems
> > 
> > 
> > No /etc/fstab - this has been discussed in other mails, but I am mentioning it 
> This is not a general problem, just in your installation.  Did you use a
> snapshot in a 1.5 environment?  If so, you have to create your
> /etc/fstab files manually, or, you have to fetch the base-cygwin package
> from the release-2 area to create /etc/fstab and /etc/fstab.d/$USER from
> your current mount points in the registry.  When installing from scratch
> from the release-2 area, you get the package for free.
> > as I am having other network problems too:
> > 
> > I cannot copy to a Hummingbird-nfs-mounted device anymore.
> > This is when mounting with nfs link X: ...; file browsing and opening works, 
> > just not create/copy.
> > With Windows mount (net use X: ...) everything works (but I don't like that 
> > mount because it works with fixed file permissions only).
> I don't have hummingbird NFS installed, just Microsoft's NFS from SFU
> resp. the default NFS clients built in to Vista and 2008.  Works fine
> for me.  There's code in Cygwin 1.7 to work with these NFS clients, see
> I have no
> idea how hummingbird NFS works.  If you want support for this NFS
> client, Cygwin needs code from you.  For a start, please build the
> attached source code and run it with the path to the drive, like this:
>   $ gcc -g -o GetVolInfo GetVolInfo.c -lntdll
>   $ ./GetVolInfo /cygdrive/x
> or
>   $ GetVolInfo x:/
> Paste the output in your reply.

Device Type        : 7
Characteristics    : 10
FileFsObjectIdInformation failed, c000000d
Volume Name        : </home/demsn702>
Serial Number      : 2651466048
Max Filenamelength : 255
Filesystemname     : <HCLNFS>
Flags              : 2

> > rlogin does not work anymore; it just hangs.
> > 
Any idea about this?

> > ----------------------
> > Path problems
> > 
> > 
> > rsh does not work anymore:
> > 	- complains about missing /usr/bin/rlogin (which has moved to /bin)
> > 
> > 
> > man does not work anymore:
> > sh: /usr/bin/tbl: No such file or directory
> > sh: /usr/bin/nroff: No such file or directory
> > (I wonder why man tries to invoke these using absolute pathnames...)
> fstab problem, probably.  Works for me.
I don't see how fstab should be related to these path problems. Maybe your comment 
refers to the above? (Maybe I should have split the problems into different issues anyway...)
Actually, looking again, I see with 1.5 (and no fstab which did not reappear when I 
reverted), there is this kind of double mount or re-mount which effectively maps /usr/bin 
to /bin. I had wondered about the purpose of this before. Is it good to use this trick 
to fix situations where programs (like rsh) refer to /usr/bin to get them find their 
sub-programs in /bin? Wouldn't it be better to install those applications (tbl, nroff, ...) 
in /usr/bin in the first place (I see that's where they are on my Linux)?

> > ----------------------
> > File system problem (weird)
> > 
> > 
> > I had a shell script "x." which mysteriously was renamed to "x" after the update.
> > I could rename it back to "x.", though.
> Files with trailing dots (or spaces) are not supported by native Windows
> apps and, FWIW, by Cygwin 1.5.  Since Cygwin 1.7 uses native NT
> functions for file access exclusively, this restriction doesn't apply to
> 1.7 anymore.  I can't reproduce any problems with 1.7 with such files,
> and the 1.5 behaviour is normal and expected sice the underlying Win32
> functions can't handle these files.  How and what should have
> mysteriously renamed the file in the first place beats me.
> > After I reverted to cygwin 1.5 (for network problems described above), 
> > the file is not available anymore; it appears in ls -l as follows:
> > ??????????? ? ?              ?         ?            ? x.
> > and is not accessible by either "x." or "x" from either cygwin or Windows.
> > (Since I cannot create another "y." now, I am not sure how I originally created the "x." file, 
> > but it had been there and I regularly called it as "x." on the command line.)
> Sorry, I have some doubts.  Neither native Win32 apps, nor Cygwin 1.5
> apps can access these files since the trailing dots and spaces
> restriction is implied by the Win32 layer.  Is that a file on the NFS
> share?  If so, there's a chance that the hummingbird NFS client is doing
> some translations for the sake of Win32 apps, but that's not under
> Cygwin's control.  Using Cygwin 1.7 I can create and manipulate these
> files fine, on local NTFS file systems as well as on NFS shares (using
> the MS client).  With 1.5 or native apps, no chance.
Just to answer your question: No, it was a local file. Also I cannot copy an "x." file 
from an NFS drive to the local drive (with 1.5). As I said, I cannot reproduce the 
situation, I'm very sorry this will probably remain mysterious.

Kind regards,

Unsubscribe info:
Problem reports:

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