This is the mail archive of the
mailing list for the Cygwin project.
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
> http://cygwin.com/ml/cygwin-developers/2008-05/msg00029.html 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
> $ 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
FILE_CASE_SENSITIVE_SEARCH : FALSE
FILE_CASE_PRESERVED_NAMES : TRUE
FILE_UNICODE_ON_DISK : FALSE
FILE_PERSISTENT_ACLS : FALSE
FILE_FILE_COMPRESSION : FALSE
FILE_VOLUME_QUOTAS : FALSE
FILE_SUPPORTS_SPARSE_FILES : FALSE
FILE_VOLUME_IS_COMPRESSED : FALSE
FILE_SUPPORTS_OBJECT_IDS : FALSE
FILE_SUPPORTS_ENCRYPTION : FALSE
FILE_NAMED_STREAMS : FALSE
FILE_READ_ONLY_VOLUME : FALSE
FILE_SEQUENTIAL_WRITE_ONCE : FALSE
FILE_SUPPORTS_TRANSACTIONS : FALSE
> > 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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html