links broken during a backup (not restore), need more info on how they work to fix file bug with vendor
Hi, I believe my backup program (CMS ABS Bounceback) is mucking with the links in my cygwin and work directories when it is creating a backup. It doesn't appear to affect links created by windows, only those created by cygwin. I don't fully understand the cygwin links: there are some that end in .lnk and are close to windows shortcuts, and there are others that don't end in .lnk and start with !symlink. Both get broken. The files still exist, but I get the message /usr/bin/vi: /usr/bin/vi: cannot execute binary file. vi looks like a plain file and contains !symlinkvim.exe. Running vim works fine. It happened to me a few weeks ago and wasn't sure why. I re-installed cygwin fixed all the shortcuts in my working/compiled src directories by deleting and recreating them. Is there an easier way to fix this? I found one post in the archives saying try attrib +R, but that didn't help at all, on either kind of link. I've searched the mailing lists and google and wasn't able to find any help for my problem. I know people here will say it's a problem with the application, but if I go to the manufacturer they'll say cyg-what(?), our software works fine with windows. Some sample links in /bin, commands executed under cygwin on windows xp. $ ls -la vi ksh.exe.* -rwx--+ 1 usd11620 memememe 319 Apr 18 10:24 ksh.exe.lnk -rwx--+ 1 usd11620 Users 18 Apr 18 08:12 vi $ attrib ksh.exe.* C:\cygwin\bin\ksh.exe.lnk $ attrib vi C:\cygwin\bin\vi $ cat vi !symlinkvim.exe $ ksh bash: ksh: command not found $ ksh.exe.lnk /usr/bin/ksh.exe.lnk: /usr/bin/ksh.exe.lnk: cannot execute binary file $ cat /usr/bin/ksh.exe.lnk | tr -c [:print:] . L..F.P.O. .:i.+00.../C:\...:.1..8D5..cygwin..$8.-.8..c.y.g.w.i.n.0.1..8bin..8...8..b.i.n.B.2.x/n. .pdksh.exe.*8...8..p.d.k.s.h...e.x.e.pdksh.exe..pdksh.exe $ cygcheck -s Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 1829k 2008/04/17 C:\cygwin\bin\cygwin1.dll Cygwin DLL version info: DLL version: 1.5.25 DLL epoch: 19 DLL bad signal mask: 19005 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 156 Shared data: 4 DLL identifier: cygwin1 Mount registry: 2 Cygnus registry name: Cygnus Solutions Cygwin registry name: Cygwin Program options name: Program Options Cygwin mount registry name: mounts v2 Cygdrive flags: cygdrive flags Cygdrive prefix: cygdrive prefix Cygdrive default prefix: Build date: Thu Apr 17 12:11:03 CEST 2008 CVS tag: cr-0x5f1 Shared id: cygwin1S4 -- See Exclusive Video: 10th Annual Young Hollywood Awards http://www.hollywoodlife.net/younghollywoodawards2008/ -- 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: links broken during a backup (not restore), need more info on how they work to fix file bug with vendor
On Fri, 16 May 2008, vapid vapid wrote: Hi, I believe my backup program (CMS ABS Bounceback) is mucking with the links in my cygwin and work directories when it is creating a backup. It doesn't appear to affect links created by windows, only those created by cygwin. I don't fully understand the cygwin links: there are some that end in .lnk and are close to windows shortcuts, and there are others that don't end in .lnk and start with !symlink. Both get broken. The files still exist, but I get the message /usr/bin/vi: /usr/bin/vi: cannot execute binary file. vi looks like a plain file and contains !symlinkvim.exe. Running vim works fine. It happened to me a few weeks ago and wasn't sure why. I re-installed cygwin fixed all the shortcuts in my working/compiled src directories by deleting and recreating them. Is there an easier way to fix this? I found one post in the archives saying try attrib +R, but that didn't help at all, on either kind of link. You need to use attrib +R on .lnk files and attrib +S on the plain-text links. On a side note, you can (re)create plain-text symlinks from the command line by using CYGWIN=nowinsymlinks ln -s FILE DEST. I've searched the mailing lists and google and wasn't able to find any help for my problem. I know people here will say it's a problem with the application, but if I go to the manufacturer they'll say cyg-what(?), our software works fine with windows. Just tell them that a backup program has no business clearing read-only and system attributes on any files. HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! That which is hateful to you, do not do to your neighbor. That is the whole Torah; the rest is commentary. Go and study it. -- Rabbi Hillel -- 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: links broken during a backup (not restore), need more info on how they work to fix file bug with vendor
On Fri, May 16, 2008 at 04:30:40PM -0400, Igor Peshansky wrote: On Fri, 16 May 2008, vapid vapid wrote: Hi, I believe my backup program (CMS ABS Bounceback) is mucking with the links in my cygwin and work directories when it is creating a backup. It doesn't appear to affect links created by windows, only those created by cygwin. I don't fully understand the cygwin links: there are some that end in .lnk and are close to windows shortcuts, and there are others that don't end in .lnk and start with !symlink. Both get broken. The files still exist, but I get the message /usr/bin/vi: /usr/bin/vi: cannot execute binary file. vi looks like a plain file and contains !symlinkvim.exe. Running vim works fine. It happened to me a few weeks ago and wasn't sure why. I re-installed cygwin fixed all the shortcuts in my working/compiled src directories by deleting and recreating them. Is there an easier way to fix this? I found one post in the archives saying try attrib +R, but that didn't help at all, on either kind of link. You need to use attrib +R on .lnk files and attrib +S on the plain-text links. On a side note, you can (re)create plain-text symlinks from the command line by using CYGWIN=nowinsymlinks ln -s FILE DEST. I've searched the mailing lists and google and wasn't able to find any help for my problem. I know people here will say it's a problem with the application, but if I go to the manufacturer they'll say cyg-what(?), our software works fine with windows. Just tell them that a backup program has no business clearing read-only and system attributes on any files. I would actually expect that they probably are just reading the .lnk information and ignoring the cygwin bits. Even if they preserve the read-onlyness of the .lnk file, unless they preserve the file in its entirety it won't be recognized. cgf -- 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: links broken during a backup (not restore), need more info on how they work to fix file bug with vendor
Thank you for the quick response Igor.
You need to use attrib +R on .lnk files and attrib +S on the
plain-text links.
I swear I tried attrib +R on both types of links earlier, but I must
have only tried the plain-text ones. It does fix the .lnk's as you
said. I'm using these two [slow] commands to fix up my system.
find / \( -name cygdrive -o -name proc -o -name dev \) -prune -o -name \*.lnk
-print -exec bash -c 'attrib +R `cygpath -d \{}\`' \;
find / \( -name cygdrive -o -name proc -o -name dev \) -prune -o -type f -exec
bash -c 'grep ^\\!symlink {} attrib +S `cygpath -d \{}\` ' \;
They scan through the cygwin root and any disks you have explicitly
mounted. I don't think it would actually hurt stuff on the windows side
of the disk, but I am trying to stay out of those directories. I'm
fairly certain the second one is safe everywhere, but the first one
may +R some non-cygwin links, if you have mounted windows directories.
This doesn't seem to affect windows; the shortcut still work in explorer.
The windows created shortcuts don't seem to work in bash with or without
the +R, which is fine with me.
Maybe someone can come up with a fancier find. I had to spawn a bash to
use the and delay the evaluation of the `cygpath {}`. There's a lot of
quoting to deal with spaces in filenames.
--
See Exclusive Video: 10th Annual Young Hollywood Awards
http://www.hollywoodlife.net/younghollywoodawards2008/
--
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: links broken during a backup (not restore), need more info on how they work to fix file bug with vendor
Just tell them that a backup program has no business clearing read-only and system attributes on any files. I would actually expect that they probably are just reading the .lnk information and ignoring the cygwin bits. Even if they preserve the read-onlyness of the .lnk file, unless they preserve the file in its entirety it won't be recognized. My issue was that they messed up my disk __during the backup__. I would be more understanding if it was during the restore. There's no reason for a backup program to modify my harddisk (unless it's keeping status in its config/log directory). It should treat my disk as a read only device. -- See Exclusive Video: 10th Annual Young Hollywood Awards http://www.hollywoodlife.net/younghollywoodawards2008/ -- 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: links broken during a backup (not restore), need more info on how they work to fix file bug with vendor
[EMAIL PROTECTED] wrote:
Maybe someone can come up with a fancier find. I had to spawn a bash to
use the and delay the evaluation of the `cygpath {}`. There's a lot of
quoting to deal with spaces in filenames.
You can speed things up a lot by only running cygpath once, e.g.:
(echo @echo off; \
find / -name \*.lnk | cygpath -w -f - | \
perl -ne 'chomp; print attrib +R \$_\\n') doit.bat
cmd.exe doit.bat
Brian
--
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: links broken during a backup (not restore), need more info on how they work to fix file bug with vendor
On Fri, May 16, 2008 at 06:02:38PM -0500, vapid vapid wrote: Just tell them that a backup program has no business clearing read-only and system attributes on any files. I would actually expect that they probably are just reading the .lnk information and ignoring the cygwin bits. Even if they preserve the read-onlyness of the .lnk file, unless they preserve the file in its entirety it won't be recognized. My issue was that they messed up my disk __during the backup__. I would be more understanding if it was during the restore. There's no reason for a backup program to modify my harddisk (unless it's keeping status in its config/log directory). It should treat my disk as a read only device. That's for sure. That really seems like a bug. cgf -- 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: links broken during a backup (not restore), need more info on how they work to fix file bug with vendor
On Fri, 16 May 2008, vapid wrote:
Thank you for the quick response Igor.
You need to use attrib +R on .lnk files and attrib +S on the
plain-text links.
I swear I tried attrib +R on both types of links earlier, but I must
have only tried the plain-text ones. It does fix the .lnk's as you
said. I'm using these two [slow] commands to fix up my system.
find / \( -name cygdrive -o -name proc -o -name dev \) -prune -o -name \*.lnk
-print -exec bash -c 'attrib +R `cygpath -d \{}\`' \;
find / \( -name cygdrive -o -name proc -o -name dev \) -prune -o -type f
-exec bash -c 'grep ^\\!symlink {} attrib +S `cygpath -d \{}\` '
\;
They scan through the cygwin root and any disks you have explicitly
mounted. I don't think it would actually hurt stuff on the windows side
of the disk, but I am trying to stay out of those directories. I'm
fairly certain the second one is safe everywhere, but the first one
may +R some non-cygwin links, if you have mounted windows directories.
This doesn't seem to affect windows; the shortcut still work in explorer.
The windows created shortcuts don't seem to work in bash with or without
the +R, which is fine with me.
Maybe someone can come up with a fancier find. I had to spawn a bash to
use the and delay the evaluation of the `cygpath {}`. There's a lot of
quoting to deal with spaces in filenames.
You're spawning way too many processes here (though you do have to run one
attrib per file). I'd go with something like this:
find / \( -name cygdrive -o -name proc -o -name dev \) -prune -o \
-name \*.lnk -print | \
cygpath -w -f - | perl -pe 's,\n,\0,' | \
xargs -tr0 -n1 attrib +R
find / -mindepth 1 -maxdepth 1 \
\! -name cygdrive \! -name proc \! -name dev -print0 | \
xargs -r0 grep -lRF '^!symlink' | \
cygpath -w -f - | perl -pe 's,\n,\0,' | \
xargs -tr0 -n1 attrib +S
(not tested, but should work barring typos).
HTH,
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!)
|,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
That which is hateful to you, do not do to your neighbor. That is the whole
Torah; the rest is commentary. Go and study it. -- Rabbi Hillel
--
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/
