This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]