> 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 > 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 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_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: 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. Kind regards, Thomas -- 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/
