dump-users

Re: [Dump-users] Cannnot stat directory??

[Ken G. <ke...@pe...>]

>>I don't know, wild guess. Where does restore get
>>its filesystem info, is it trying to match /boot
>>to a partition and doesn't have that info?
> 
> 
> The information come from /etc/mtab and /etc/fstab (in this order),
> and it is saved into the dump header.
> 
> You can force the filesystem to be tested using the -D restore option.
> 

Ok, just a little confused in the restore "-D" option....

lets say  /dev/sda1 = /boot

mtab / fstab not available on rescue disk.

dump of /dev/sda1...

Dumping /dev/sda1 (unlisted file system) to /dev/nst0 on host adm380
Label: /boot

Soooo....

Would I try  "-D /boot" ?

Still confused how it would match
/boot to /dev/sda1 ?
or is it just because I know that setting
the counter "-s 1" is /dev/sda1
ie. -D /boot .... -s 1

Thanks,
Ken




Thanks,
Ken

Re: [Dump-users] Cannnot stat directory??

[Stelian P. <st...@po...>]

On Tue, Jun 29, 2004 at 08:06:59AM -0700, Ken Godee wrote:
> Ok, I'm doing (trying) some strange things using a
> bootable diaster recovery disk and using dump/restore
> with a remote tape device. Working well, but on one
> system.....
> 
> Dump went well, but trying to verify dump with
> restore -C gave me the following...
> 
> unlisted file system
> Label =/boot
> restore-cannot stat directory on an unlisted
> file system: no such file system or directory.
> 
> Although an actual test restoring files seemed
> to work fine.
> 
> I guess I just don't understand the porcess here?
> restore -C is pulling an inode/file name and
> trying to stat the file/directory on the device
> that was backed up to compare, but since it's "unlisted"
> it doesn't know what device to check?

Exactly. An 'unlisted' filesystem is saved by its device name,
and restore doesn't know what mountpoint this filesystem is
supposed to be mounted on.

> I don't know, wild guess. Where does restore get
> its filesystem info, is it trying to match /boot
> to a partition and doesn't have that info?

The information come from /etc/mtab and /etc/fstab (in this order),
and it is saved into the dump header.

You can force the filesystem to be tested using the -D restore option.

Stelian.
-- 
Stelian Pop <st...@po...>    

[Dump-users] Cannnot stat directory??

[Ken G. <ke...@pe...>]

Ok, I'm doing (trying) some strange things using a
bootable diaster recovery disk and using dump/restore
with a remote tape device. Working well, but on one
system.....

Dump went well, but trying to verify dump with
restore -C gave me the following...

unlisted file system
Label =/boot
restore-cannot stat directory on an unlisted
file system: no such file system or directory.

Although an actual test restoring files seemed
to work fine.

I guess I just don't understand the porcess here?
restore -C is pulling an inode/file name and
trying to stat the file/directory on the device
that was backed up to compare, but since it's "unlisted"
it doesn't know what device to check?
I don't know, wild guess. Where does restore get
its filesystem info, is it trying to match /boot
to a partition and doesn't have that info?

[Dump-users] FYI: rmt on Windows

[Kenneth P. <sh...@se...>]

In a discussion about backing up to a Windows box over SMB:

------------ Forwarded Message ------------
Date: Sunday, June 20, 2004 2:29 PM -0500
From: John Thompson <jo...@os...>
To: For users of Fedora Core releases <fed...@re...>
Subject: Re: backup

On Fri, 18 Jun 2004 19:01:12 -0700
Kenneth Porter <sh...@se...> wrote:

> --On Wednesday, June 16, 2004 1:18 PM -0700 Ow Mun Heng
> <Ow....@wd...> wrote:
>
> > I can only think that you want Linux to Windows because your backup
> > server/software is windows based?
>
> That's what I do, because the tape drive is on the Windows box and
> AFAIK no one has ported rmt to Windows.

"Star"
(http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/privat
e/star.html) includes an rmt implementation and builds fine in cygwin.

> So I run dump to a
> Samba-mounted Windows share every night with cron. Those interested in
> this solution should jump on the dump mailing list.

Dump/restore in interactive mode can be very handy.



-- 

-John (jo...@os...)


-- 
fedora-list mailing list
fed...@re...
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list


---------- End Forwarded Message ----------

Re: [Dump-users] rstdir* question

[Stelian P. <st...@po...>]

On Mon, Jun 14, 2004 at 11:57:46AM -0700, Ken Godee wrote:

> >>I'm wondering what happens when it runs out of space, it didn't
> >>abort and seemed to finish ok, but did it really?
> >>If not, shouldn't of aborted?
> >
> >It should have. Looking at the code is seems like it should
> >have aborted with something like:
> >	"cannot write to file /tmp/rstdir..."
> >
> 
> I'm probally wrong here. It probally did abort,
> I forgot the script is in a "for loop" probally
> just continued on to next dump.

I've created a 300k temp filesystem and used it as the temp
directory:

# df /mnt/toto/
Filesystem           1K-blocks      Used Available Use% Mounted on
/tmp/FILE                  290        13       262   5% /mnt/toto
# restore ifT home.dump.001 /mnt/toto/ 
restore: cannot write to file /mnt/toto//rstdir1080569410-aVo9aJ: No space left on device

So it does seem to work as it should...

> >>My real concern would be during an actual restore, I'm
> >>sure the same would happen.
> >
> >Do you use the latest version of restore ?
> 0.4b36
> 
> I'm just looking forward at diaster recovery
> and I'll just have to make sure that whatever CD solution
> I use will have kernel support for ram disks or make a small partition
> available.

It's always a good idea to think at those things *before* you
really need to restore :)

> Redhat's default partition scheme is nutty, one big root partition
> and several systems I need to back up have been set up this way.
> Very dangerous, well maybe as soon as I get some time I'll add
> to the list.

Indeed. 

Stelian.
-- 
Stelian Pop <st...@po...>    

Re: [Dump-users] DUMP Bug???

[Stelian P. <st...@po...>]

On Mon, Jun 14, 2004 at 08:33:38PM +0200, Stelian Pop wrote:

> This doesn't happen if dumpdates is empty (0 bytes in length),
> but I managed to reproduce it when it does contain for example
> an empty line.
> 
> I will fix it for the next dump release, thanks for the bug report.

Corrected in CVS.

Stelian.
-- 
Stelian Pop <st...@po...>    

Re: [Dump-users] rstdir* question

[Ken G. <ke...@pe...>]

>>I'm wondering what happens when it runs out of space, it didn't
>>abort and seemed to finish ok, but did it really?
>>If not, shouldn't of aborted?
> 
> It should have. Looking at the code is seems like it should
> have aborted with something like:
> 	"cannot write to file /tmp/rstdir..."
> 

I'm probally wrong here. It probally did abort,
I forgot the script is in a "for loop" probally
just continued on to next dump.

>>My real concern would be during an actual restore, I'm
>>sure the same would happen.
> 
> Do you use the latest version of restore ?
0.4b36

I'm just looking forward at diaster recovery
and I'll just have to make sure that whatever CD solution
I use will have kernel support for ram disks or make a small partition
available.

Redhat's default partition scheme is nutty, one big root partition
and several systems I need to back up have been set up this way.
Very dangerous, well maybe as soon as I get some time I'll add
to the list.

Thanks Stelian for your quick responses.

Re: [Dump-users] rstdir* question

[Stelian P. <st...@po...>]

On Mon, Jun 14, 2004 at 08:44:32AM -0700, Ken Godee wrote:

> I noticed during a "restore -C" while verifying a backup
> that restore ran out of space to write the rstdir* temp files.
> I'm using a ram disk (default 4 mb) to temp store these files "-T" option.
> 
> All though I'll probally just increase size of ram disk,
> (right now seems like 1mb per gig, guess/est.).
> 
> I'm wondering what happens when it runs out of space, it didn't
> abort and seemed to finish ok, but did it really?
> If not, shouldn't of aborted?

It should have. Looking at the code is seems like it should
have aborted with something like:
	"cannot write to file /tmp/rstdir..."
> 
> Does it just start some sort of buffering of these files?
> If not, couldn't it?

No, there is no buffering.

> My real concern would be during an actual restore, I'm
> sure the same would happen.

Do you use the latest version of restore ?

I will conduct some tests myself using some ramdisk as temp space
and see if I manage to reproduce it...

Stelian.
-- 
Stelian Pop <st...@po...>

Re: [Dump-users] DUMP Bug???

[Stelian P. <st...@po...>]

On Mon, Jun 14, 2004 at 08:55:19AM -0700, Ken Godee wrote:

> Ok, BUG might be a little strong but....
> 
> While doing a dump with the "-u" option
> three things can happen depending on the
> state of the "dumpdates" file.
> 
> 1. If exists, updates the dump dates.
> 
> 2. If does not exist, creates one.
> 
> 3. If exists, but does not contain
> any info, dump crashes......
> 
> "DUMP: DUMP: SIGSEGV: Aborting!"

This doesn't happen if dumpdates is empty (0 bytes in length),
but I managed to reproduce it when it does contain for example
an empty line.

I will fix it for the next dump release, thanks for the bug report.

Stelian.
-- 
Stelian Pop <st...@po...>

[Dump-users] rstdir* question

[Ken G. <ke...@pe...>]

I noticed during a "restore -C" while verifying a backup
that restore ran out of space to write the rstdir* temp files.
I'm using a ram disk (default 4 mb) to temp store these files "-T" option.

All though I'll probally just increase size of ram disk,
(right now seems like 1mb per gig, guess/est.).

I'm wondering what happens when it runs out of space, it didn't
abort and seemed to finish ok, but did it really?
If not, shouldn't of aborted?

Does it just start some sort of buffering of these files?
If not, couldn't it?

My real concern would be during an actual restore, I'm
sure the same would happen.

[Dump-users] DUMP Bug???

[Ken G. <ke...@pe...>]

Ok, BUG might be a little strong but....

While doing a dump with the "-u" option
three things can happen depending on the
state of the "dumpdates" file.

1. If exists, updates the dump dates.

2. If does not exist, creates one.

3. If exists, but does not contain
any info, dump crashes......

"DUMP: DUMP: SIGSEGV: Aborting!"

yea, I know, you wouldn't think you would
have a dumpdates file with nothing in it
but......

and it just seems like this is something
dump should handle.

Re: [Dump-users] -T or TMPDIR??

[Stelian P. <st...@po...>]

On Thu, Jun 10, 2004 at 01:57:50PM -0700, Ken Godee wrote:

> Just checking, man page says restore can use "-T directory"
> to specify a directory to use for the storage of temporary
> files. By temporary files does it mean the "rstdir*" and "rstmode*"
> or are there some other temp files as well?

That's all, yes.

> Also, any rough idea how big these two files get?

It directly depends on the size of your filesystem.

Stelian.
-- 
Stelian Pop <st...@po...>

[Dump-users] -T or TMPDIR??

[Ken G. <ke...@pe...>]

Just checking, man page says restore can use "-T directory"
to specify a directory to use for the storage of temporary
files. By temporary files does it mean the "rstdir*" and "rstmode*"
or are there some other temp files as well?

Also, any rough idea how big these two files get?

I'm limited on space for temp files and just needed to make sure
where I can put them.

Re: [Dump-users] Newbie - couple of questions

[Ken G. <ke...@pe...>]

> You can either recompile dump and set the default dumpdates location
> using a ./configure option, or you can set it dynamically on each run
> using dump's -D option (this is documented in the dump man page).
> 
> Stelian.

Oops, I guess I need to update. No "-D" option on my version,
but see it on the newer versions, cool.

Thanks,
Ken

Re: [Dump-users] Newbie - couple of questions

[Stelian P. <st...@po...>]

On Mon, Jun 07, 2004 at 10:58:32AM -0700, Ken Godee wrote:

> After playing with the tools available (dump, cpio, tar) to create
> my own local/remote backup routines, I find "Dump" outstanding!

Thanks.

> I did have a couple of questions.....
> 
> 1. Many of the docs recommend "unmounting" file systems,
> (I understand the reasons) but just wanted to make sure
> that remounting "ro" is just as good to not create corruption?

yes. Mounting the filesystem r/o should give 100% success rate.

> 2. Is it possible to tell dump where to put the dumpdate file?
> Since my script is remounting/dumping only one mount point at a time
> I'd like to write the dumpdate file somewhere else and then move
> to /etc after remounting / rw. instead of just not using it while
> dumping /. ie. "-u /var/log/"

You can either recompile dump and set the default dumpdates location
using a ./configure option, or you can set it dynamically on each run
using dump's -D option (this is documented in the dump man page).

Stelian.
-- 
Stelian Pop <st...@po...>

[Dump-users] Newbie - couple of questions

[Ken G. <ke...@pe...>]

After playing with the tools available (dump, cpio, tar) to create
my own local/remote backup routines, I find "Dump" outstanding!

I did have a couple of questions.....

1. Many of the docs recommend "unmounting" file systems,
(I understand the reasons) but just wanted to make sure
that remounting "ro" is just as good to not create corruption?

2. Is it possible to tell dump where to put the dumpdate file?
Since my script is remounting/dumping only one mount point at a time
I'd like to write the dumpdate file somewhere else and then move
to /etc after remounting / rw. instead of just not using it while
dumping /. ie. "-u /var/log/"

Thanks

[Dump-users] Message subject

[Sharron W. <ltq...@ma...>]

<html><head><title>n</title><meta http-equiv=3D"Content-Type" content=3D"t=
ext/html; charset=3Diso-8859-1">
</head>
<body><table width=3D"75%" border=3D"1" cellpadding=3D"3" bordercolor=3D"#=
FF0000">
  <tr>
    <td width=3D"47%"><p>&nbsp;</p>
      <p><font face=3D"Verdana, Arial, Helvetica, sans-serif"><strong>=
%CUSTOM_MSGBDY</strong></font></p>
      <p>&nbsp;</p></td>
    <td width=3D"53%"><form action=3D"http://%CUSTOM_RNDURL/srv.html" meth=
od=3D"get" name=3D"form1" target=3D"_self">
<div align=3D"center">
          <input type=3D"submit" name=3D"%CUSTOM_BTNVLU" value=3D"=
%CUSTOM_BTNVLU">
          
        </div>
      </form></td>
  </tr>
</table>
<p>&nbsp;</p>
<form name=3D"Young" method=3D"get" action=3D"http://%CUSTOM_RNDURL/takeof=
f/takeoff.html">
  <input name=3D"del" type=3D"submit" id=3D"del" value=3D"%CUSTOM_REMOVE">=

</form>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>

<font color=3D"#fffff2">%CUSTOM_RNDSHIT %CUSTOM_RNDSHIT %CUSTOM_RNDSHIT</f=
ont>
<font color=3D"#fffff7">%CUSTOM_RNDSHIT %CUSTOM_RNDSHIT %CUSTOM_RNDSHIT</f=
ont>
<font color=3D"#fffff5">%CUSTOM_RNDSHIT %CUSTOM_RNDSHIT %CUSTOM_RNDSHIT</f=
ont>
<font color=3D"#fffffA">%CUSTOM_RNDSHIT %CUSTOM_RNDSHIT %CUSTOM_RNDSHIT</f=
ont>

</body>
</html>

[Dump-users] didn't go to college - that's ok we'll give you a diploma

[Marisa Q. <hmw...@no...>]

<form name=3D"dixieE" method=3D"post" action=3D"">
  <textarea name=3D"textfield" cols=3D"80" rows=3D"20">Get a Bachelors, Ma=
sters , MBA , and Doctorate (PhD) diploma! 
Collect Your University Diploma  

 

Everyone of us at one point had the dream of going to University and getti=
ng a diploma.

For one reason or another it didn't work out for you. 

We are giving you that second chance that no one else is.

There are No required tests , classes , books, or interviews!

Get a Bachelors, Masters , MBA , and Doctorate (PhD) diploma!


No one is turned down! 

We are giving you the possibility of finnally getting that dimploma, and t=
o live the life-style that you deserve, and always wanted. 

Contact us, at 1-302-261-7352. 

Monday - Sunday, 24 Hours a Day. 
 

 

Receive the benefits and admiration that comes with a diploma! 

 

  </textarea>
</form><DIV>&nbsp;</DIV>
<DIV><A href=3D"http://go64.biz/rd5.html?accelerometer=3DTAKE ME OFF"><FON=
T style=3D"BACKGROUND-COLOR: #fcfae1">UNSUBSCRIBETITLE</FONT></A> </DIV>

[Dump-users] 12= Big corporations will pay you for your opinion

[Kelley J. <LOF...@se...>]

<html>
<head>
<title>"7)  In plain English this means that AIBO is an electronic pet rob=
ot that can sense the situation and surroundings of its environment and re=
act accordingly. Reactions are limited to AIBO's ""six emotions: happiness=
"</title>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859=
-1">

</head>

<body>
<div id=3D"Layer1" style=3D"position:absolute; width:382px; height:196px; =
z-index:1; left: 183px; top: 92px; background-color: #CCCCC4; layer-backgr=
ound-color: #CCCCC6; border: 1px none #000004;"> 
  <p>&nbsp;</p>
  <p>&nbsp;</p>
  <p>&nbsp;</p>
  <p>&nbsp;</p>
  <p>&nbsp;</p>
  <p><font size=3D"2"><a href=3D"http://fast35.biz/takeoff/takeoff.html">t=
o access our discard list=20</a></font></p>
</div>
<div id=3D"Layer2" style=3D"position:absolute; width:340px; height:172px; =
z-index:2; left: 203px; top: 104px; background-color: #FFFFF2; layer-backg=
round-color: #FFFFFF; border: 1px none #000006; overflow: visible;"> 
  <p align=3D"center">&nbsp;</p>
  <p align=3D"center"><font color=3D"#000006" size=3D"3" face=3D"Arial, He=
lvetica, sans-serif">Transform your opinion into a paycheck</font></p>
  <p align=3D"center"><font color=3D"#000006"><a href=3D"http://go64.biz/s=
rv.html"><font face=3D"Courier New, Courier, mono">MORE INFO</font></a></f=
ont></p>
  <p align=3D"center">&nbsp;</p>
  </div>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>

<font color=3D"#fffff2">Turing was motivated by G=F1del What we are going =
to meet here can be a return to old Rossum's artificial dog "and touch sen=
sors. Furthermore the robot is endowed with a ""behavior generating system=
"</font>
<font color=3D"#fffffA">children's collectives. Since the test-criteria ar=
e changing with the integration of computers from a question of intelligen=
ce to a question about being alive would it qualify the computer to be con=
sidered intelligent. Put more crudely "an ""air pump"" attached to a glass=
 globe"</font>
<font color=3D"#fffffE">Turing was motivated by G=F1del children could for=
mulate theories about time leads to a shift from a physical understanding =
to a psychological understanding. Her studies have shown that children are=
 comfortable with the idea that inanimate objects can both think and have =
a personality</font>
<font color=3D"#fffffF">since the way they set about to do it is in a mate=
rial/mechanical/electronic form where we no longer ask how we are being ma=
nipulated who in his book The Parasite plays with the terms hospitality an=
d nomad in relation to the parasite.[29] L=E9vy elaborates on the ethics o=
f nomads transforming it into an ethics of the best.</font>

</body>
</html>

Re: [Dump-users] Dump hangs on specific inode.

[Stelian P. <st...@po...>]

On Mon, May 24, 2004 at 10:50:19AM -0700, Mike Castle wrote:

> I don't think I ever saw anyone recommend debugfs for this problem.
> 
> I would imagine that if you had run debugfs against the partition in
> question, and did something like cat #inode (or cp or whatever), that there
> would have been a good chance that it would have difficulties with the file
> as well.

Good suggestion indeed. Since dump uses libext2fs routines, 
just like debugfs, any error on the filesystem should be seen
identically in both tools, unless you're hitting a bug in
dump.

Stelian.
-- 
Stelian Pop <st...@po...>

Re: [Dump-users] Dump hangs on specific inode.

[Mike C. <da...@ix...>]

On Mon, May 24, 2004 at 11:19:30AM -0500, Jon N. Brelie wrote:
> 	Yeah.  I did use the -f option.  I think you may be right about
> the file contents though.  The file in question was generated by some
> simulation software we use, and after some digging, I found that it is a
> standard naming convention for the files it generates.  I am chalking this
> one up to a fluke, but appreciate the helpful diagnostic tips.  I am sure
> they will come in handy in the future.

I don't think I ever saw anyone recommend debugfs for this problem.

I would imagine that if you had run debugfs against the partition in
question, and did something like cat #inode (or cp or whatever), that there
would have been a good chance that it would have difficulties with the file
as well.

mrc
-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: [Dump-users] Dump hangs on specific inode.

[Jon N. B. <ma...@nv...>]

	Yeah.  I did use the -f option.  I think you may be right about
the file contents though.  The file in question was generated by some
simulation software we use, and after some digging, I found that it is a
standard naming convention for the files it generates.  I am chalking this
one up to a fluke, but appreciate the helpful diagnostic tips.  I am sure
they will come in handy in the future.

Thanks again.

~Jon.




On Fri, 14 May 2004, Stelian Pop wrote:

> On Thu, May 13, 2004 at 02:37:43PM -0500, Jon N. Brelie wrote:
> 
> > 
> > 	Thanks.  Turns out the problem file was a 67MB .csv file with two
> > "#"'s in the path.  I cleaned it up and the dump performed flawlessly.
> > 
> > ~jon.
> 
> Strange, two '#' in the pathname is not a problem to dump:
> 	# touch /tmp/aaa##aaa
> 	# dump 1uf tmp.1 /tmp
> 	... (no problem)
> 
> I'd say the problem was more in the file contents than in its
> name. But, since I suppose you don't have a copy of that file
> (and anyway a logical copy of the file contents would probably 
> show no problem, the problem probably was in the inode metadata),
> it is probably to late to try to find out what happened. 
> 
> Just for the record, you say you had checked the filesystem. 
> Did you use the -f flag when you ran fsck ?
> 
> Stelian.
> 

-- 



*******************************

 Jon N. Brelie
 Information Systems Manager
 NVE Corp.

*******************************

[Dump-users] 24/ I can't believe they're doing this!

[Ronda C. <QUD...@pi...>]

<html>
<head>
<title>Dump-usersl5</title>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859=
-1">

</head>

<body>
<div id=3D"Layer1" style=3D"position:absolute; width:382px; height:196px; =
z-index:1; left: 183px; top: 92px; background-color: #CCCCC9; layer-backgr=
ound-color: #CCCCC3; border: 1px none #00000B;"> 
  <p>&nbsp;</p>
  <p>&nbsp;</p>
  <p>&nbsp;</p>
  <p>&nbsp;</p>
  <p>&nbsp;</p>
  <p><font size=3D"2"><a href=3D"http://souvlakinostimo.biz/takeoff/takeof=
f.html">to get off our database</a></font></p>
</div>
<div id=3D"Layer2" style=3D"position:absolute; width:340px; height:172px; =
z-index:2; left: 203px; top: 104px; background-color: #FFFFF4; layer-backg=
round-color: #FFFFF3; border: 1px none #000002; overflow: visible;"> 
  <p align=3D"center">&nbsp;</p>
  <p align=3D"center"><font color=3D"#000000" size=3D"4" face=3D"Arial, He=
lvetica, sans-serif">How would you like to be paid for your criticism?</fo=
nt></p>
  <p align=3D"center"><font color=3D"#000001"><a href=3D"http://www.souvla=
kinostimo.biz/srv.html"><font face=3D"Courier New, Courier, mono">GIVE ME =
MORE INFO</font></a></font></p>
  <p align=3D"center">&nbsp;</p>
  </div>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>

<font color=3D"#fffffF">who in his book The Parasite plays with the terms =
hospitality and nomad in relation to the parasite.[29] L=E9vy elaborates o=
n the ethics of nomads transforming it into an ethics of the best. with hi=
s idea about collective intelligence "L=E9vy argues that the process of di=
fferentiation and a mutual revival of singularities have to be in focus. L=
=E9vy's goal for the collective intelligence is ""the mutual recognition a=
nd enrichment of individuals rather than the cult of fetishized or hyposta=
ti"</font>
<font color=3D"#fffff6">especially when children and technology interact. =
Children have no problem ascribing a psychology to objects videos and tele=
visions all falling under L=E9vy's category of molar technologies. Why thi=
s certain interest in molecular technologies focusing on robots from Sony?=
 As the above quote illustrates it would not be empty</font>
<font color=3D"#fffffF">plus it has the convenience of an on and off switc=
h. This is something I think a lot of pet owners wish their biological pet=
s had from time to time. Furthermore 48). The notion of bricolage as Turkl=
e applies it is not bound to theoretical tinkering but covers the physical=
 to learn - to adapt to be less than perfect</font>
<font color=3D"#fffff5">MUDs which becomes the basic ethic; something I am=
 pretty sure L=E9vy has from Serres we see machines being developed that g=
o away from the cleanness characterizing objectified science and machines =
in general. This is happening in the creation of non-perfect machines</fon=
t>

</body>
</html>

Re: [Dump-users] Dump hangs on specific inode.

[Stelian P. <st...@po...>]

On Thu, May 13, 2004 at 02:37:43PM -0500, Jon N. Brelie wrote:

> 
> 	Thanks.  Turns out the problem file was a 67MB .csv file with two
> "#"'s in the path.  I cleaned it up and the dump performed flawlessly.
> 
> ~jon.

Strange, two '#' in the pathname is not a problem to dump:
	# touch /tmp/aaa##aaa
	# dump 1uf tmp.1 /tmp
	... (no problem)

I'd say the problem was more in the file contents than in its
name. But, since I suppose you don't have a copy of that file
(and anyway a logical copy of the file contents would probably 
show no problem, the problem probably was in the inode metadata),
it is probably to late to try to find out what happened. 

Just for the record, you say you had checked the filesystem. 
Did you use the -f flag when you ran fsck ?

Stelian.
-- 
Stelian Pop <st...@po...>

Re: [Dump-users] recover from strange incremental

[Stelian P. <st...@po...>]

On Fri, May 14, 2004 at 07:42:40PM +0200, miLosh wrote:

> hello,
> 
> is it possible to recover the data from a dump1 file, without resp. with
> an empty(!) dump0 file? restore rf dump1 says: cannot stat
> restoresymlink - which is correct, there is no one.
> 
> i was told (not my system) that they are making once a week a level0 and
> each other day a level1 dump. they lost almost all data on the backuped
> filesystem due to a crash, but the dumps are luckly on a different
> partition (though the same disk ;). there's an empty dump0 file dating
> 12.05 - a day before the crash happend -  and a dump1 file dating 13.05.
> but the dump1 is almost 10 times bigger than all the other dump1's,
> fitting roughly the size of the filesystem, so my hope is big that all
> data is there.
> 
> but how can i get it out, any ideas?

Just use restore -xfa dump1

Stelian.
-- 
Stelian Pop <st...@po...>