On Fri, 2 Aug 2024, Tim Woodall wrote:
# Reading through this now I'm not absolutely sure that those hoops I
# jump throught to sign the repo are needed...
Just confirmed the gpg stuff is not needed
# Not sure why I have that proxy bit in here either. I think I'm
# installing from a file re
On Fri, 2 Aug 2024, daggs wrote:
Greetings,
I'm working on an automated Debian installation without network access.
I've discovered the --make-tarball and --unpack-tarball switches which I use to
create the tarball and use it as repo.
the initial deployment is this: debootstrap --arch amd64 --
Greetings,
I'm working on an automated Debian installation without network access.
I've discovered the --make-tarball and --unpack-tarball switches which I use to
create the tarball and use it as repo.
the initial deployment is this: debootstrap --arch amd64 --unpack-tarball
/tmp/debs.tar.gz sta
On 24/09/2022 02:37, jr wrote:
On Thursday, 22 September 2022 at 16:30:05 UTC+1, Max Nikulin wrote:
...
Debian mail list archive has a rare mhonarc configuration that adds
reply to list action (usually only reply to sender is available) and
these mailto: links contain proper In-Reply-To value
ht
On Fri, 23 Sep 2022 19:18:35 -0400
The Wanderer wrote:
> I think the question was about a way/place/method to manually add such
> headers from within Gmail, so that they can be present even when
> replying to a message from within the digest, so that replies can be
> made correctly while subscrib
On 2022-09-23 at 16:24, Thomas Schmitt wrote:
> Hi,
>
> jr wrote:
>
>> I [...] cannot find an obvious (any!) place where headers could be set [...]
>> I [...] hope that someone can/will supply Gmail specific instructions
>
> The normal way to participate is to subscribe your mail address at
>
Hi,
jr wrote:
> I [...] cannot find an obvious (any!) place where headers could be set [...]
> I [...] hope that someone can/will supply Gmail specific instructions
The normal way to participate is to subscribe your mail address at
https://lists.debian.org/debian-user/
or by sending a mail to
hi,
a single reply re the mail headers issue.
On Thursday, 22 September 2022 at 09:20:06 UTC+1, Thomas Schmitt wrote:
> ...
> Your mails lack headers like "In-Reply-To:" or "References:", ...
On Thursday, 22 September 2022 at 09:30:05 UTC+1, Tixy wrote:
> ...
> For a lot (most?) of us, your mes
On 22/09/2022 14:00, jr wrote:
On Wednesday, 21 September 2022 at 17:20:05 UTC+1, Markus Schönhaber wrote:
Could you please stop using a mail client that starts a new thread with
every message you send?
Please use something instead that really creates a reply when you are
replying to someone (i
On Thu, 22 Sep 2022 08:00:34 +0100
jr wrote:
> ouch. I read the digest,
That could be your problem. If you would subscribe as a regular user,
rather than to the digests (or in addition to) and reply to those
messages, you might solve the problem.
--
Does anybody read signatures any more?
htt
On Thu, 2022-09-22 at 08:00 +0100, jr wrote:
[...]
> > [a reply that isn't one]
> >
> > Could you please stop using a mail client that starts a new thread with
> > every message you send?
> > Please use something instead that really creates a reply when you are
> > replying to someone (i. e. somet
Hi,
jr wrote:
> I see a single thread only. cannot see "a new thread [started] with
> every message", sorry.
Your mails lack headers like "In-Reply-To:" or "References:", which
should tell the Message Id of the mail to which you answer resp. some
or all IDs of the thread. (My "References:" only
> That listing almost certainly includes subdirectory names. Hence your
> issues.
> ...
> That's why you're getting duplicates.
> ...
> As I told you several posts ago, if you're feeding "find" output -- or
> in your case, "locate" output, whic
the right tool for anything other than an interactive
file listing. It would be better yet to use `find /home/jr -type f
-print0` which would output:
/home/jr/dir1/file1\0/home/jr/dir2/file2\0
[disclaimer: the rest of this assumes GNU tar; other tar implementations
will have different behavi
21.09.22, 17:29 +0200, jr wrote:
[a reply that isn't one]
Could you please stop using a mail client that starts a new thread with
every message you send?
Please use something instead that really creates a reply when you are
replying to someone (i. e. something that sets the
In-Reply-To/Refere
ames. Hence your
issues.
You're feeding both a filename *and* its containing directory name to
tar. Tar recurses into the directory whose name you have fed it, and
then also grabs the file whose name you have fed it.
That's why you're getting duplicates.
As I told you several
; > ;-))
> Do you need a DEMONSTRATION of how it is broken and wrong?
>
> unicorn:/tmp/x$ mkdir -p sub1/sub2
> unicorn:/tmp/x$ touch sub1/sub2/{file1,file2,'* file3 *'}
> unicorn:/tmp/x$ not_safe=$(find . -type f)
> unicorn:/tmp/x$ tar cf ../foo.tar $not_safe
sure.
On Wed, Sep 21, 2022 at 12:31:58PM +0100, jr wrote:
> > > $ tar -cvWf $arcname $fnames
> > >
> > > where $fnames initially was a list in a variable (this is preparing a
> > > shell script), then I switched to storing in those in a file and
> > > $ tar
me that perhaps the OP did
> > > something like this: ...
> > > unicorn:/tmp/x$ find . | tar cv --files-from=- -f ../foo.tar
> >
> > I prefer 'locate' to 'find'. an no guessing involved, as I wrote on
> > the 18th, the invocation was:
> > $ tar
On Tue, Sep 20, 2022 at 10:19:50PM +0100, jr wrote:
> hi,
>
> On Tuesday, 20 September 2022 at 12:30:05 UTC+1, Greg Wooledge wrote:
> > ...
> > With this new information, it occurs to me that perhaps the OP did
> > something like this: ...
> > unicorn:/tmp/x$
hi,
On Tuesday, 20 September 2022 at 12:30:05 UTC+1, Greg Wooledge wrote:
> ...
> With this new information, it occurs to me that perhaps the OP did
> something like this: ...
> unicorn:/tmp/x$ find . | tar cv --files-from=- -f ../foo.tar
I prefer 'locate' to 'find&
> It seems some files are present multiple times in your list.
>
> echo text >file.txt
> tar cvWf test.tar file.txt file.txt
> tar tvf test.tar
Sorry, I deleted this message, and then had a thought a few minutes later,
so I'm quoting text from the mailing list archive.
Wi
Hi,
Max Nikulin wrote:
> It seems some files are present multiple times in your list.
> tar cvWf test.tar file.txt file.txt
Well if it is that easy to create the situation, i can test what happens
on restoring the tarball:
$ tar cvf test.tar x x
x
x
$ rm x
rm: remove regular f
On 19/09/2022 02:37, jr wrote:
when I saw the links and started investigating, I tried cat for the names, ie
$ tar -cvWf $arcname $(cat $fnames)
adding one or two file names on the command line works as expected,
supplying names from list and or file produces those links.
It seems some
On Monday, 19 September 2022 at 10:10:05 UTC+1, Thomas Schmitt wrote:
> ...
> But you could create a small ext filesystem in a file, mount it and make
> experiments with it.
oh, that's an excellent suggestion. thanks. will do that in the coming days.
> > the "machine" is a VM, pre-installed by
On Mon, Sep 19, 2022 at 08:24:08AM +0100, jr wrote:
> _thank you_. another question, if you don't mind: what will happen
> if I extract such an archive on a "normal" computer with ext3/4
> filesystems? (don't want to .. experiment with this)
Since none of us can reproduce your archive, only you
make
experiments with it.
From the view of the Linux kernel the expectable unpacking activities of
tar should not be too exotic. I am quite sure that attempts to link a
file to itself have happened in the last 25+ years:
$ ln x x
ln: failed to create hard link ‘x’: File exists
> the &quo
hi,
On Sun, 18 Sept 2022 at 21:39, Thomas Schmitt wrote:
> Will Mengarini wrote:
> > Note that the file-type character "h" (the leftmost character in your
> > second line of output) isn't documented ...
> The 'h' probably comes from {...}
> which
es from
https://sources.debian.org/src/tar/1.34%2Bdfsg-1/src/list.c/#L1188
which converts tar file type LNKTYPE to 'h'.
This type is set when dump_hard_link() detects that there is already
a file in the archive with the same device and inode number:
https://sources.debian.org/src/tar
* jr [22-09/18=Su 12:59 +0100]:
> When I create an archive with '-cvWf' I'm used to finding only the files
> specified, but every time I use 'tar' on this Debian, there is a "link" for
> each and every file. Why? eg:
> -rw--- jr/jr 256 2022-0
hi,
> What kind of file system are the files sitting on?
btrfs. the system is the pre-installed (on Chromebooks) Debian VM.
> What are the *exact* tar commands that you used, to create the archive,
> and to get that partial listing that you gave?
initially from a shell script, ass
On Sun, 18 Sep 2022 12:59:21 +0100
jr wrote:
> I hope someone can help me to make 'tar' "behave" as expected. tia.
>
> when I create an archive with '-cvWf' I'm used to finding only the
> files specified, but every time I use 'tar' on
On Sun, Sep 18, 2022 at 12:59:21PM +0100, jr wrote:
> when I create an archive with '-cvWf' I'm used to finding only the files
> specified, but every time I use 'tar' on this Debian, there is a "link" for
> each and every file. why? eg:
> -rw-
hi,
I hope someone can help me to make 'tar' "behave" as expected. tia.
when I create an archive with '-cvWf' I'm used to finding only the files
specified, but every time I use 'tar' on this Debian, there is a "link" for
each and every
mick crane [2020-06-15T19:01:32+01] wrote:
> I think my memory has packed up.
Mine too, and I like GNU's long-option style because I remember them
easily. They are also kind of self-documenting code in shell scripts.
tar --create --verbose --xz --file archive.tar.xz directory/to
On Mon, Jun 15, 2020 at 07:30:31PM +0100, mick crane wrote:
yes I see that now
but without hyphen "f" can be anywhere
Yes and no: any of the keys can be in any location, but their arguments
must follow the key list in the order that the keys appear. For example:
tar cbf 20 fo
On Mon, Jun 15, 2020 at 02:34:24PM -0500, David Wright wrote:
It appears you've also forgotten about man pages as well as google.
The man page explains the difference between hyphenated and
unhyphenated forms, and helpfully even gives a single example
written in both forms:
tar cfv
On Mon 15 Jun 2020 at 19:30:31 (+0100), mick crane wrote:
> On 2020-06-15 19:17, Thomas Pircher wrote:
> > mick crane wrote:
> > > I thought you put the options after a hyphen with tar ?
> >
> > Tar accepts 3 styles of options. The style with a single dash is c
On 2020-06-15 19:17, Thomas Pircher wrote:
mick crane wrote:
I thought you put the options after a hyphen with tar ?
Tar accepts 3 styles of options. The style with a single dash is called
the 'UNIX' or 'short-option' style in the man page.
"tar -cfvz archive_file.t
On Mon 15 Jun 2020 at 19:24:00 +0100, mick crane wrote:
> On 2020-06-15 19:07, Brian wrote:
> > On Mon 15 Jun 2020 at 19:01:32 +0100, mick crane wrote:
> >
> > > I think my memory has packed up.
> >
> > So has your ability to use a search engine. Try
> &g
On Mon, Jun 15, 2020 at 07:01:32PM +0100, mick crane wrote:
> I think my memory has packed up.
> I thought you put the options after a hyphen with tar ?
> "tar -cfvz archive_file.tgz ./directory_to_archive"
> doesn't work.
> "tar cfvz archive_file.tgz ./
On 2020-06-15 19:07, Brian wrote:
On Mon 15 Jun 2020 at 19:01:32 +0100, mick crane wrote:
I think my memory has packed up.
So has your ability to use a search engine. Try
tar options hyphen
Ok I see what the confusion was "f" has to be the last of the options if
using hyp
mick crane wrote:
> I thought you put the options after a hyphen with tar ?
Tar accepts 3 styles of options. The style with a single dash is called
the 'UNIX' or 'short-option' style in the man page.
> "tar -cfvz archive_file.tgz ./directory_to_archive"
>
On Mon, Jun 15, 2020 at 13:02 mick crane wrote:
> I think my memory has packed up.
> I thought you put the options after a hyphen with tar ?
> "tar -cfvz archive_file.tgz ./directory_to_archive"
You do for modern use, but the 'f' has to be the last arg in that
incantation.
-Tom
On Mon 15 Jun 2020 at 19:01:32 +0100, mick crane wrote:
> I think my memory has packed up.
So has your ability to use a search engine. Try
tar options hyphen
--
Brian.
I think my memory has packed up.
I thought you put the options after a hyphen with tar ?
"tar -cfvz archive_file.tgz ./directory_to_archive"
doesn't work.
"tar cfvz archive_file.tgz ./directory_to_archive"
works
mick
--
Key ID4BFEBB31
On 2018-01-26, rhkra...@gmail.com wrote:
> On Friday, January 26, 2018 05:50:45 AM Curt wrote:
>> On 2018-01-26, David Wright wrote:
>> >> Yes, my bad, that is intended for the amanda list, whose new owner is
>> >> attempting to emulate yahoo all those years ago by claiming copyright on
>> >> eve
On Friday, January 26, 2018 05:50:45 AM Curt wrote:
> On 2018-01-26, David Wright wrote:
> >> Yes, my bad, that is intended for the amanda list, whose new owner is
> >> attempting to emulate yahoo all those years ago by claiming copyright on
> >> everthing the server passes thru. Yahoo got burned
On 2018-01-26, David Wright wrote:
>>
>> Yes, my bad, that is intended for the amanda list, whose new owner is
>> attempting to emulate yahoo all those years ago by claiming copyright on
>> everthing the server passes thru. Yahoo got burned at the stake in court
>> over that, and now CARBONITE
On Friday 26 January 2018 04:52:54 Curt wrote:
> On 2018-01-26, Gene Heskett wrote:
> > In the meantime I'm trying to train this old dog to delete those 2
> > lines when the message is not aimed at the amanda list.
>
> Just let us talk to Maurice and we'll work it out with him.
>
> > Cheers, Gene
On Thursday, 25 January 2018 21:14:24 CET Michael Fothergill wrote:
> I ran the tar -xf command:
>
> root@mikef-PC:/usr/src# tar -xf linux-4.14.15.tar.xz
you can use 'a' for automatic and 'v' for verbose. E.g.:
tar -axvf linux-4.14.15.tar.xz
HTH
--
https://g
On 2018-01-26, Gene Heskett wrote:
>
> In the meantime I'm trying to train this old dog to delete those 2 lines
> when the message is not aimed at the amanda list.
Just let us talk to Maurice and we'll work it out with him.
> Cheers, Gene Heskett
--
“True terror is to wake up one morning and
>
> > > > I am trying to extract files from a tar xz file.
> > > >
> > > > The file is a kernel file.
> > > >
> > > > I ran the tar -xf command:
> >
> > [Snipped]
> >
> > > Cheers, Gene Heskett
> > >
On Thursday 25 January 2018 21:45:46 David Wright wrote:
> On Thu 25 Jan 2018 at 19:54:14 (-0500), Gene Heskett wrote:
> > On Thursday 25 January 2018 15:51:47 Brian wrote:
> > > On Thu 25 Jan 2018 at 15:42:15 -0500, Gene Heskett wrote:
> > > [Snipped more]
> > >
> > > > Cheers, Gene Heskett
> > >
On Thu, 25 Jan 2018 20:51:47 + Brian sent:
> On Thu 25 Jan 2018 at 15:42:15 -0500, Gene Heskett wrote:
>
> > On Thursday 25 January 2018 15:14:24 Michael Fothergill wrote:
> >
> > > Dear folks,
> > >
> > > I am trying to extract files from a
On Thu 25 Jan 2018 at 19:54:14 (-0500), Gene Heskett wrote:
> On Thursday 25 January 2018 15:51:47 Brian wrote:
>
> > On Thu 25 Jan 2018 at 15:42:15 -0500, Gene Heskett wrote:
> > [Snipped more]
> >
> > > Cheers, Gene Heskett
> > > The above content, added by Maurice E. Heskett, is Copyright 2018
On Thursday 25 January 2018 15:51:47 Brian wrote:
> On Thu 25 Jan 2018 at 15:42:15 -0500, Gene Heskett wrote:
> > On Thursday 25 January 2018 15:14:24 Michael Fothergill wrote:
> > > Dear folks,
> > >
> > > I am trying to extract files from a tar xz file.
&
On Thu, Jan 25, 2018 at 10:00:08PM +0100, Michael Lange wrote:
> On Thu, 25 Jan 2018 20:14:24 +
> Michael Fothergill wrote:
>
> > Dear folks,
> >
> > I am trying to extract files from a tar xz file.
>
> Why bother with a command line and not just do it fr
On Thu, 25 Jan 2018 20:14:24 +
Michael Fothergill wrote:
> Dear folks,
>
> I am trying to extract files from a tar xz file.
Why bother with a command line and not just do it from a gui file
manager's context menu? Xfe and pcmanfm and probably the others as well
handle t
On 25 January 2018 at 20:33, Greg Wooledge wrote:
> On Thu, Jan 25, 2018 at 08:14:24PM +, Michael Fothergill wrote:
> > root@mikef-PC:/usr/src# tar -xf linux-4.14.15.tar.xz
> >
> > Can anyone think of a command that will let me know where the files
> > went/confi
On Thu 25 Jan 2018 at 15:42:15 -0500, Gene Heskett wrote:
> On Thursday 25 January 2018 15:14:24 Michael Fothergill wrote:
>
> > Dear folks,
> >
> > I am trying to extract files from a tar xz file.
> >
> > The file is a kernel file.
> >
> > I ran
On Thu, Jan 25, 2018 at 03:42:15PM -0500, Gene Heskett wrote:
> running tar xf is asking tar to do something it cannot do, at least not
> yet.
Says the wheezy user. The newer tar versions will auto-detect the
compression type and run the appropriate decompression program.
wooledg:~$ t
what you will get back.
>
> running tar xf is asking tar to do something it cannot do, at least not
> yet.
>
> man xz can be quite educational ;-)
>
>From tar(1), on a Debian stretch system:
-J, --xz
Filter the archive through xz(1).
I am relatively confident th
Gene Heskett (2018-01-25):
> It would help to run the correct unpacker. xz is relatively new, and the
> command is: xz -d packagename.xz. If its a tarball, thats what you'll
> get back. If it an image for an sd card, that's what you will get back.
>
> running t
On Thursday 25 January 2018 15:14:24 Michael Fothergill wrote:
> Dear folks,
>
> I am trying to extract files from a tar xz file.
>
> The file is a kernel file.
>
> I ran the tar -xf command:
>
> root@mikef-PC:/usr/src# tar -xf linux-4.14.15.tar.xz
>
> If you l
On Thu, Jan 25, 2018 at 08:14:24PM +, Michael Fothergill wrote:
> root@mikef-PC:/usr/src# tar -xf linux-4.14.15.tar.xz
>
> Can anyone think of a command that will let me know where the files
> went/confirm it ran properly?
Use "tar -xvf ..." to get verbose output
Michael Fothergill (2018-01-25):
> If you look at the date and time then you can see that no directories have
> been created with from it in the directory.....
tar restores the mtime of extracted files and directories. You need to
look at the ctime.
Regards,
--
Nicolas George
signatu
Dear folks,
I am trying to extract files from a tar xz file.
The file is a kernel file.
I ran the tar -xf command:
root@mikef-PC:/usr/src# tar -xf linux-4.14.15.tar.xz
If you look at the date and time then you can see that no directories have
been created with from it in the directory
ng lingering
> afterward. You would be in the clear. I would still exclude it of
> course. The possibility of archiving /dev/mem for example makes me
> nervous. :-)
Hehe indeed. I will change the tar command to exclude it completely.
> http://marc.merlins.org/perso/linux
On Mon, 8 Jun 2015 16:49:45 -0600
Bob Proulx wrote:
> Lisi Reisz wrote:
> > Bob Proulx wrote:
> > > Every file. File by file. I liked this presentation and found it
> > > quite interesting.
> > >
> > > http://marc.merlins.org/perso/linux/post_2014-01-06_My-Live-Upgrading-Many-Thousands-of-Serve
Quoting Lisi Reisz (lisi.re...@gmail.com):
> On Monday 08 June 2015 23:06:41 Bob Proulx wrote:
> > Every file. File by file. I liked this presentation and found it
> > quite interesting.
> > http://marc.merlins.org/perso/linux/post_2014-01-06_My-Live-Upgrading-Many-
> >Thousands-of-Servers-ProdNG
Lisi Reisz wrote:
> Bob Proulx wrote:
> > Every file. File by file. I liked this presentation and found it
> > quite interesting.
> >
> > http://marc.merlins.org/perso/linux/post_2014-01-06_My-Live-Upgrading-Many-Thousands-of-Servers-ProdNG-talk-at-Linux_conf_au-2014.html
That one definitely wor
On Monday 08 June 2015 23:06:41 Bob Proulx wrote:
> Every file. File by file. I liked this presentation and found it
> quite interesting.
>
>
> http://marc.merlins.org/perso/linux/post_2014-01-06_My-Live-Upgrading-Many-
>Thousands-of-Servers-ProdNG-talk-at-Linux_conf_au-2014.html
>
> Unfortunat
Linux4Bene wrote:
> schreef Bob Proulx:
> thanks for your reply and the time invested. Much appreciated.
> It does indeed seem tricky unless you go the full monty and replace the
> whole installation except for the special dirs like dev as you noted.
> In my test, I didn't get any strange results
t I have
learned not to always trust what I see in IT. In the back of my mind, I
always suspect a problem popping up when the server is in production.
>> Tar command from the backup script on the old server:
>> EXCLUDE="--exclude=proc --exclude=sys --exclude=dev/pts
>>
;
> As a start, I would do a full tar archive of the old server and start
> from there. A test on a local VM worked, with some adjustments. Both use
> Debian 7.8. The services on the old server that need to me moved:
> - Mail: Postfix, Dovecot, Spamassassin, Clamav, Postgresql, ...
Hi,
I am in the process of moving my server to another VPS.
The goal is to keep the old VPS around and convert it to backup MX & DNS
amongst other things. I will purchase the new VPS from another company so
I can't just copy the vm file/container.
As a start, I would do a full tar a
On Mon, 13 Apr 2015 15:36:33 -0500
David Wright wrote:
> Quoting Petter Adsen (pet...@synth.no):
> > On Mon, 13 Apr 2015 12:12:51 -0500
> > David Wright wrote:
> > > Have fun reading man find, though!
> >
> > petter@monster:~$ man tar | wc -l
> >
Quoting Petter Adsen (pet...@synth.no):
> On Mon, 13 Apr 2015 12:12:51 -0500
> David Wright wrote:
> > Have fun reading man find, though!
>
> petter@monster:~$ man tar | wc -l
> 540
> petter@monster:~$ man find | wc -l
> 1572
>
> :-)
Mea culpa. But, in my de
't work. Neither did '--exclude="~/.cache/*".
> >
> > I got it working by creating an empty file in ~/.cache and using the
> > filename as an argument to "--exclude-tag-under", but what was I
> > doing wrong when trying to use "--exclude"?
>
working by creating an empty file in ~/.cache and using the
> filename as an argument to "--exclude-tag-under", but what was I doing
> wrong when trying to use "--exclude"?
I didn't know tar did that. I thought most people use find to generate
the filenames for t
gt; > filename as an argument to "--exclude-tag-under", but what was I
> > doing wrong when trying to use "--exclude"?
>
> Maybe the prefix you used (~).
>
> Try with
>
> tar -cvf /dev/null --exclude=.cache $HOME | less
That was, in essence, the c
/*".
Can you send the command you used ?
It will be easier to find what's wrong.
>
> I got it working by creating an empty file in ~/.cache and using the
> filename as an argument to "--exclude-tag-under", but what was I doing
> wrong when trying to use "--
On 2015-04-13 16:15:42 +0200, Petter Adsen wrote:
> I've been trying to make a tarball of my home directory, but I want to
> exclude ~/.cache. First I tried '--exclude="~/.cache", but it didn't
> work. Neither did '--exclude="~/.cache/*".
The ~ is not expended here:
$ echo "~/foo"
~/foo
Try --ex
I've been trying to make a tarball of my home directory, but I want to
exclude ~/.cache. First I tried '--exclude="~/.cache", but it didn't
work. Neither did '--exclude="~/.cache/*".
I got it working by creating an empty file in ~/.cache and using the
filename as an argument to "--exclude-tag-unde
On Sat, 08 Nov 2014, John Conover wrote:
> and look at the ownership of the cups directory and compare it to the
> ownership in /etc.
In this example, you're not archiving etc/cups or etc, you're just
archiving etc/cups/printers.conf, which means that tar must create
etc/cups it
f the
> > directories down to the files are always root/root.
>
su
cd /
tar cvf xxx.tar etc/cups/printers.conf
cd
tar xvf /xxx.tar
ls -al etc
and look at the ownership of the cups directory and compare it to the
ownership in /etc.
This is a changed behavior in tar(1), (at least from Ubun
s are always root/root.
% fakeroot bash -c 'mkdir -p foo/bar; chown 8:8 .; chown 9:9 foo; chown 10:10
foo/bar; ls -la foo; tar -zvvtf bar.tar.gz; tar -zcf bar.tar.gz foo; rmdir -p
foo/bar; tar -zxf bar.tar.gz; ls -la foo; rmdir -p foo/bar;';
total 12
drwxr-xr-x 3 news news 4096 Nov 8 11:
Don Armstrong writes:
> On Sat, 08 Nov 2014, John Conover wrote:
> > There has been changes in the way a tar(1) restore to a temporary
> > directory constructs directory ownerships; as login theuser, in
> > ${HOME}:
>
> This looks like you're using tar --no
On Sat, 08 Nov 2014, John Conover wrote:
> There has been changes in the way a tar(1) restore to a temporary
> directory constructs directory ownerships; as login theuser, in
> ${HOME}:
This looks like you're using tar --no-same-owner, possibly via an ENV
variable or something els
There has been changes in the way a tar(1) restore to a temporary
directory constructs directory ownerships; as login theuser, in
${HOME}:
mkdir xxx xxx/yyy; touch xxx/yyy/zzz
su
Password:
# cd /
# tar cvf home/theuser/aaa.tar home/theuser/xxx
home/theuser/xxx/
home/theuser/xxx/yyy/
home
PS:
If the OP does remember the date, it might help to recover files only
from this date or at least recover only files from a given time span,
most, if not all tools provide this option too.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trou
cautions, and here is what I see
> >
> > ls -lh
> > total 5.8G
> > -r 1 xyz xyz 5.8G Jun 14 17:52 inode_17000
> >
> > tried gunzip, djview, tar -x, mplayer, etc, thinking of the possible files
> > that I had of that size. Nothing comes up. By the way
-- 1 xyz xyz 5.8G Jun 14 17:52 inode_17000
>
> tried gunzip, djview, tar -x, mplayer, etc, thinking of the possible files
> that I had of that size. Nothing comes up. By the way, did bcrypt disappear
> from wheezy?
>
> Any ideas what else could be done?
Just an idea, but wha
xyz 5.8G Jun 14 17:52 inode_17000
>
> tried gunzip, djview, tar -x, mplayer, etc, thinking of the possible files
> that I had of that size. Nothing comes up.
If the data is compressed, it will probably not be understood by
anything other than gunzip, and even not that if there is not a proper
head
ilesystem. If you *always*
> mount it read-only, do not feel that a drive failure is imminent, and
> trust the NTFS drivers, then this should be completely safe. If you
> can get even a small portion (at the beginning) of the tar.gz, you
> could (I suppose) use gzcat and then see some
inent, and
trust the NTFS drivers, then this should be completely safe. If you
can get even a small portion (at the beginning) of the tar.gz, you
could (I suppose) use gzcat and then see some of the tar contents on
stdout. Perhaps you could even find a way to re-compress it to 4.7GB
chunks, and
On Thu, Jun 13, 2013 at 10:53 PM, green wrote:
> Bob Proulx wrote at 2013-06-13 11:45 -0500:
> > Good to hear that it was not ext3!
>
> For ext3, there is the ext4magic tool. (I have not used it.)
>
Thank you guys for all your input. The mention of scalpel, scrounge-ntfs
reminded me that I shou
Bob Proulx wrote at 2013-06-13 11:45 -0500:
> Good to hear that it was not ext3!
For ext3, there is the ext4magic tool. (I have not used it.)
signature.asc
Description: Digital signature
not compress more. My
10x number might be 1.2x overall. But text and source code and
particularly data files tend to compress very well and my 10x number
might be 100x then. It all depends upon the data.)
> b) taring and then compressing?
Normally people working with tar.gz files compress t
1 - 100 of 898 matches
Mail list logo
