Bacula-users

Re: [Bacula-users] phantom filesystems in Windows

2009-04-03 16:33:18
Subject: Re: [Bacula-users] phantom filesystems in Windows
From: "Erik P. Olsen" <epodata AT gmail DOT com>
To: Kevin Keane <subscription AT kkeane DOT com>
Date: Fri, 03 Apr 2009 22:25:02 +0200
On 03/04/09 21:19, Kevin Keane wrote:
> Erik P. Olsen wrote:
>> On 03/04/09 18:56, Kevin Keane wrote:
>>  
>>> Foo wrote:
>>>    
>>>> On Thu, 02 Apr 2009 17:57:32 +0200, John Drescher
>>>> <drescherjm AT gmail DOT com>  wrote:
>>>>
>>>>        
>>>>> On Thu, Apr 2, 2009 at 11:27 AM, Kevin Keane
>>>>> <subscription AT kkeane DOT com>  wrote:
>>>>>            
>>>>>> This actually is correct behavior. If you look carefully, you will
>>>>>> see
>>>>>> that these two directories are actually not directories at all, but
>>>>>> rather junction points that simply reference other directories
>>>>>> somewhere
>>>>>> else. Windows junction points are like a cross between Linux symlinks
>>>>>> and Linux mounts.
>>>>>>
>>>>>>                 
>>>>> I would like to add to the OP that these should be ignored as they
>>>>> are  harmless.
>>>>>             
>>>> They belong to .net 2.0 and can be included explicitly. If you
>>>> don't, I  would expect .net to break in some mysterious way,
>>>> although it might break  anyway if Bacula cannot restore junction
>>>> points (can it?). At least I  include them to be sure. You'll get
>>>> warnings about them anyway if you  include the whole partition, but
>>>> that can be ignored.
>>>>
>>>> I guess if the restore doesn't work properly, you can always
>>>> reinstall  ..net (+ hotfixes/service packs) to fix it, though that's
>>>> not ideal.  Thankfully I didn't run into this so far.
>>>>         
>>> Actually, you probably should *not* include these directories
>>> explicitly. Because they are junction points, the actual data is
>>> stored somewhere else, usually on the same file system, and already
>>> is getting backed up. By including the directories explicitly, you
>>> would basically on restore create a real directory instead of a
>>> junction point, which could wreak havoc with .NET updates in the
>>> future (as well as many other issues, I'm sure).
>>>
>>>     
>> I think it would be wiser if the client instead of backing-up a
>> junction point rather would back-up
>> the actual data. It is not easy to find all junction points and treat
>> them manually. I for one would
>> not be able to perform this task, IMHO it should be done automagically
>> by the client. It would also
>> be perfect if a junction point would be recreated as part of a restore
>> operation.
>>   
> The data is backed up automatically from the location where it really
> resides (as long as the file set includes that location, of course.
> Usually, not a problem because most of these types of junction points
> simply link to neighboring directories, or at least close-by ones).
> 
I think I need to understand it better. If I interpret it correctly then a
file set including a junction will cause the actual data to be backed-up.
But what happens if the data has to be restored? Will the actual data be
restored together with the junction?

> Did you mean to respond to the group?

Yes, I am sorry I really intended to respond to the list but forgot to add
it's address to the header.

-- 
Erik.



------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users