links broken during a backup (not restore), need more info on how they work to fix & file bug with vendor

links broken during a backup (not restore), need more info on how they work to fix & file bug with vendor

[vapid vapid]

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 "!<symlink>vim.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 
!<symlink>vim.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......8....bin..........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

[Igor Peshansky]

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 "!<symlink>vim.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/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
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

[Christopher Faylor]

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 "!<symlink>vim.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

[Igor Peshansky]

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/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
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

[Christopher Faylor]

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

[Brian Dessent]

vapid@mindless.com 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

[vapid vapid]

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

[vapid]

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/