cygwin 1.7 problems: network, path, file system

cygwin 1.7 problems: network, path, file system

[Thomas Wolff]

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 
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).


rlogin does not work anymore; it just hangs.


----------------------
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...)


----------------------
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.
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.)


----------------------

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

Re: cygwin 1.7 problems: network, path, file system

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3865 bytes --]

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.

> rlogin does not work anymore; it just hangs.
> 
> 
> ----------------------
> 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.

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


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: GetVolInfo.c --]
[-- Type: text/x-c++src, Size: 7866 bytes --]

#include <stdio.h>
#include <string.h>
#include <sys/cygwin.h>
#define _WIN32_WINNT 0x0600
#include <windows.h>
#include <ddk/ntifs.h>
#include <wchar.h>

#ifndef FILE_READ_ONLY_VOLUME
#define FILE_READ_ONLY_VOLUME 0x80000
#endif
#ifndef FILE_SEQUENTIAL_WRITE_ONCE
#define FILE_SEQUENTIAL_WRITE_ONCE 0x100000
#endif
#ifndef FILE_SUPPORTS_TRANSACTIONS
#define FILE_SUPPORTS_TRANSACTIONS 0x200000
#endif

typedef struct _FILE_FS_OBJECTID_INFORMATION
{
  UCHAR ObjectId[16];
  UCHAR ExtendedInfo[48];
} FILE_FS_OBJECTID_INFORMATION, *PFILE_FS_OBJECTID_INFORMATION;

BOOLEAN NTAPI RtlCreateUnicodeStringFromAsciiz (PUNICODE_STRING, PCSTR);
BOOLEAN NTAPI RtlTimeToSecondsSince1970 (PLARGE_INTEGER, PULONG);

int __stdcall
sys_wcstombs (char *tgt, int tlen, const WCHAR *src, int slen)
{
  int ret;
    
  ret = WideCharToMultiByte (GetOEMCP (), 0, src, slen, tgt, tlen, NULL, NULL);
  if (ret)
    tgt[ret < tlen ? ret : tlen - 1] = '\0';
  return ret;
}   

#define SAMBA_EXTENDED_INFO_MAGIC 0x536d4261 /* "SmBa" */
#define SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH 28
#pragma pack(push,4)
struct smb_extended_info { 
  DWORD         samba_magic;             /* Always SAMBA_EXTRA_INFO_MAGIC */
  DWORD         samba_version;           /* Major/Minor/Release/Revision */
  DWORD         samba_subversion;        /* Prerelease/RC/Vendor patch */
  LARGE_INTEGER samba_gitcommitdate;
  char   samba_version_string[SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH];
};
#pragma pack(pop)

void
print_objectid (PFILE_FS_OBJECTID_INFORMATION pfi)
{
      struct smb_extended_info *ei = (struct smb_extended_info *)
				     &pfi->ExtendedInfo;
      time_t t;
      int i;

      printf ("Object Id          : ");
      for (i = 0; i < 16; ++i)
        printf ("%02x ", pfi->ObjectId[i]);
      puts ("");
      printf ("Extended Info      : ");
      if (ei->samba_magic == SAMBA_EXTENDED_INFO_MAGIC)
        {
	  printf ("Samba!!!\n");
	  printf ("                   : magic          <%08lx>\n", ei->samba_magic);
	  printf ("                   : version        <%08lx>\n", ei->samba_version);
	  printf ("                   : subversion     <%08lx>\n", ei->samba_subversion);
	  RtlTimeToSecondsSince1970 (&ei->samba_gitcommitdate, &t);
	  printf ("                   : GIT commit     <%.24s>\n", ctime (&t));
	  printf ("                   : version string <%s>", ei->samba_version_string);
	}
      else
        printf ("Not Samba");
      for (i = 0; i < 48; ++i)
	{
	  if (i == 0 || i == 16 || i == 32)
	    printf ("\n                     ");
	  printf ("%02x ", pfi->ExtendedInfo[i]);
	}
      puts ("");
}

int
main (int argc, char **argv)
{
  char winpath[256];
  DWORD flags = 0;
  HANDLE h;
  UNICODE_STRING wpath;
  UNICODE_STRING upath;
  OBJECT_ATTRIBUTES attr;
  IO_STATUS_BLOCK io;
  NTSTATUS stat;
  ULONG ret;
  char buf[1024];
  char name[256];

  if (argc < 2)
    {
      fprintf (stderr, "usage: %s path\n", argv[0]);
      return 1;
    }
  cygwin_conv_to_full_win32_path (argv[1], winpath);
  if (!RtlCreateUnicodeStringFromAsciiz (&wpath, winpath))
    {
      fprintf (stderr, "RtlCreateUnicodeStringFromAsciiz failed\n");
      return 1;
    }
  if (!RtlDosPathNameToNtPathName_U (wpath.Buffer, &upath, NULL, NULL))
    {
      fprintf (stderr, "RtlDosPathNameToNtPathName_U failed\n");
      RtlFreeUnicodeString (&wpath);
      return 1;
    }
  InitializeObjectAttributes (&attr, &upath, OBJ_CASE_INSENSITIVE, NULL, NULL);

  stat = ZwOpenFile (&h, READ_CONTROL, &attr, &io, FILE_SHARE_VALID_FLAGS,
		     FILE_OPEN_FOR_BACKUP_INTENT);
  if (!NT_SUCCESS (stat) && stat == STATUS_NO_MEDIA_IN_DEVICE)
    {
      upath.Length = 6 * sizeof (WCHAR);
      stat = ZwOpenFile (&h, READ_CONTROL, &attr, &io, FILE_SHARE_VALID_FLAGS, 0);
    }
  if (!NT_SUCCESS (stat))
    {
      char buf[1024];
      wcstombs (buf, upath.Buffer, upath.Length / sizeof (WCHAR));
      buf[upath.Length / sizeof (WCHAR)] = '\0';
      fprintf (stderr, "ZwOpenFile(%s) failed, %08x\n", buf, stat);
      return 1;
    }

  stat = ZwQueryVolumeInformationFile (h, &io, buf, 1024,
				       FileFsDeviceInformation);
  if (NT_SUCCESS (stat))
    {
      PFILE_FS_DEVICE_INFORMATION pfi =
	    (PFILE_FS_DEVICE_INFORMATION) buf;
      printf ("Device Type        : %lx\n", pfi->DeviceType);
      printf ("Characteristics    : %lx\n", pfi->Characteristics);
    }
  else
    fprintf (stderr, "FileFsDeviceInformation failed, %08lx\n", stat);

  stat = ZwQueryVolumeInformationFile (h, &io, buf, 1024,
				       FileFsObjectIdInformation);
  if (NT_SUCCESS (stat))
    print_objectid ((PFILE_FS_OBJECTID_INFORMATION) buf);
  else
    fprintf (stderr, "FileFsObjectIdInformation failed, %08lx\n", stat);

  stat = ZwQueryVolumeInformationFile (h, &io, buf, 1024,
				       FileFsVolumeInformation);
  if (NT_SUCCESS (stat))
    {
      PFILE_FS_VOLUME_INFORMATION pfi =
	    (PFILE_FS_VOLUME_INFORMATION) buf;
      if (pfi->VolumeLabelLength)
	{
	  sys_wcstombs (name, 256, pfi->VolumeLabel,
			pfi->VolumeLabelLength / sizeof (WCHAR));
	  printf ("Volume Name        : <%s>\n", name);
	}
      else
	printf ("Volume Name        : <>\n");
      printf ("Serial Number      : %lu\n", pfi->VolumeSerialNumber);
    }
  else
    fprintf (stderr, "FileFsVolumeInformation failed, %08lx\n", stat);

  stat = ZwQueryVolumeInformationFile (h, &io, buf, 1024,
				       FileFsAttributeInformation);
  if (NT_SUCCESS (stat))
    {
      PFILE_FS_ATTRIBUTE_INFORMATION pfi =
	    (PFILE_FS_ATTRIBUTE_INFORMATION) buf;
      printf ("Max Filenamelength : %lu\n",pfi->MaximumComponentNameLength);
      sys_wcstombs (name, 256, pfi->FileSystemName,
		    pfi->FileSystemNameLength / sizeof (WCHAR));
      printf ("Filesystemname     : <%s>\n", name);
      printf ("Flags              : %lx\n",
	      flags = pfi->FileSystemAttributes);

      printf ("  FILE_CASE_SENSITIVE_SEARCH  : %s\n",
	      (flags & FILE_CASE_SENSITIVE_SEARCH) ? "TRUE" : "FALSE");
      printf ("  FILE_CASE_PRESERVED_NAMES   : %s\n",
	      (flags & FILE_CASE_PRESERVED_NAMES) ? "TRUE" : "FALSE");
      printf ("  FILE_UNICODE_ON_DISK        : %s\n",
	      (flags & FILE_UNICODE_ON_DISK) ? "TRUE" : "FALSE");
      printf ("  FILE_PERSISTENT_ACLS        : %s\n",
	      (flags & FILE_PERSISTENT_ACLS) ? "TRUE" : "FALSE");
      printf ("  FILE_FILE_COMPRESSION       : %s\n",
	      (flags & FILE_FILE_COMPRESSION) ? "TRUE" : "FALSE");
      printf ("  FILE_VOLUME_QUOTAS          : %s\n",
	      (flags & FILE_VOLUME_QUOTAS) ? "TRUE" : "FALSE");
      printf ("  FILE_SUPPORTS_SPARSE_FILES  : %s\n",
	      (flags & FILE_SUPPORTS_SPARSE_FILES) ? "TRUE" : "FALSE");
      printf ("  FILE_SUPPORTS_REPARSE_POINTS: %s\n",
	      (flags & FILE_SUPPORTS_REPARSE_POINTS) ? "TRUE" : "FALSE");
      printf ("  FILE_SUPPORTS_REMOTE_STORAGE: %s\n",
	      (flags & FILE_SUPPORTS_REMOTE_STORAGE) ? "TRUE" : "FALSE");
      printf ("  FILE_VOLUME_IS_COMPRESSED   : %s\n",
	      (flags & FILE_VOLUME_IS_COMPRESSED) ? "TRUE" : "FALSE");
      printf ("  FILE_SUPPORTS_OBJECT_IDS    : %s\n",
	      (flags & FILE_SUPPORTS_OBJECT_IDS) ? "TRUE" : "FALSE");
      printf ("  FILE_SUPPORTS_ENCRYPTION    : %s\n",
	      (flags & FILE_SUPPORTS_ENCRYPTION) ? "TRUE" : "FALSE");
      printf ("  FILE_NAMED_STREAMS          : %s\n",
	      (flags & FILE_NAMED_STREAMS) ? "TRUE" : "FALSE");
      printf ("  FILE_READ_ONLY_VOLUME       : %s\n",
	      (flags & FILE_READ_ONLY_VOLUME) ? "TRUE" : "FALSE");
      printf ("  FILE_SEQUENTIAL_WRITE_ONCE  : %s\n",
	      (flags & FILE_SEQUENTIAL_WRITE_ONCE) ? "TRUE" : "FALSE");
      printf ("  FILE_SUPPORTS_TRANSACTIONS  : %s\n",
	      (flags & FILE_SUPPORTS_TRANSACTIONS) ? "TRUE" : "FALSE");
    }
  else
    fprintf (stderr, "FileFsAttributeInformation failed, %08lx\n", stat);

  ZwClose (h);
  RtlFreeUnicodeString (&upath);
  RtlFreeUnicodeString (&wpath);
  return 0;
}


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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

Re: cygwin 1.7 problems: network, path, file system

[Corinna Vinschen]

Thomas, ping?

On Jun 18 12:53, Corinna Vinschen wrote:
> 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
          ^^^^^^^^^^^^^^^^^^^^^^^^^^
  Alternatively developer documentation from.  Hummingbird.  I don't
  know if they have opened their API, but as a customer you should get
  some information.

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

This is still a first step I'm interested in...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: cygwin 1.7 problems: network, path, file system

[Thomas Wolff]

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

Re: cygwin 1.7 problems: network, path, file system

[Corinna Vinschen]

On Jun 24 13:52, Thomas Wolff wrote:
> 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

Thanks.  So it won't be treated like the MS NFS client, that's good news.
Rather, it will be treated like FAT (in 1.5 and 1.7), which is the safest
fallback.

Anyway, that doesn't help with your copy problem.  This can't be solved
without more details (when, how, debug output, the usual routine).

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

Yes, that's a bug in the current 1.7.  I'll fix it.

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

No.  In 1.5 you have registry mount points which point from /usr/bin to the
underlying Win32 path.  1.7 uses an fstab file.  SInce you don't have an
fstab file, you don't have the /usr/bin and /usr/lib mount points.  I wrote
in my first reply how to fix this.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: cygwin 1.7 problems: network, path, file system

[Thomas Wolff]

Just to finally provide some positive feedback: I installed cygwin 1.7 
again this year and the problems I experienced with Hummingbird NFS do 
not occur anymore.

> Thomas, ping?
> 
> On Jun 18 12:53, Corinna Vinschen wrote:
>> 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
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^
>   Alternatively developer documentation from.  Hummingbird.  I don't
>   know if they have opened their API, but as a customer you should get
>   some information.
> 
>> 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.
> 
> This is still a first step I'm interested in...
> 
> 
> Corinna
> 


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