More: [1.7] packaging problem? Both /usr/bin/ and /usr/lib/ are non-empty

Tue May 5 13:07:00 GMT 2009

 > That's very odd.
 > Those files are created by the postinstall script,
 > which is run by setup.exe in a "real" cygwin shell.
 > That is, it's just a bash script that runs
 > ..
 > BUT, because it's in a bash shell, it OUGHT to know
 > about all of the mount points, especially
 > cygwin-1.7 (cat /etc/fstab):                   !!!!
 > .. C:/cygwin-1.7 / some_fs binary 0 0
 > .. C:/cygwin-1.7/bin /usr/bin some_fs binary 0 0
 > .. C:/cygwin-1.7/lib /usr/lib some_fs binary 0 0

OK, thank you very much. Your account of what goes on reveals the cause 
of the problem, which is local to *my machine* as you anticipated. (See 
the line ending !!!!)

Running Cygwin [1.7] from a mobile drive whose driveletter might vary 
from host to host or usage to usage, and which I won't necessarily know, 
and don't want to have to find out, I do not have a /etc/fstab file. 
Every instance of Cygwin is initiated by a Windows batch command file 
that discovers the driveletter for itself and uses it to write a bespoke 
/etc/fstab. Only then is the shell started. At the end of the session 
the tailored file /etc/fstab is deleted.

(Cygwin [1.5] is also run from a mobile drive with the same requirement 
to identify and utilise its driveletter at each usage. But for 1.5 
mounts are handled differently and at updating this problem does not arise.)

In future I can precede [1.7] updates by using the same idea: run a 
batch file to create /etc/fstab but which then runs setup.exe rather 
than starting a shell.

Thank you very much. (This behaviour - mobile drive - is probably viewed 
as eccentric minority behaviour requiring no special attention in 
setup.exe, but I think I am not the only one using Cygwin in this way, 
as very recent posts have shown.)


Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list