On 2022-09-26 at 19:16, David Wright wrote:
> On Mon 26 Sep 2022 at 21:31:55 (+0200), Emanuel Berg wrote:
>
>> Greg Wooledge wrote:
>>> The entire thread was a result of your assumption that exif would
>>> NOT write the words "Wrote file" if the input file had no exif
>>> tag in it. This turned
On Mon 26 Sep 2022 at 21:31:55 (+0200), Emanuel Berg wrote:
> Greg Wooledge wrote:
>
> >> Look more, quote less ...
> >>
> >> for f in **/*.jpg; do exif --remove -o $f $f; done | grep
> > 'Wrote
> >> file' | wc -l # 2277 (1st invocation)
> >>
> >> for f in **/*
debian-user wrote:
>> In programming the focus is perhaps better, for something
>> idempotent, something like: Do it the first time.
>> Don't screw it up the second time? And don't do the
>> computing if it doesn't need to be done?
>
> Sorry, but idempotence says nothing at all about
> computation
> In programming the focus is perhaps better, for something
> idempotent, something like: Do it the first time. Don't screw
> it up the second time? And don't do the computing if it
> doesn't need to be done?
Sorry, but idempotence says nothing at all about computational
efficiency or cost.
And
Greg Wooledge wrote:
>> Look more, quote less ...
>>
>> for f in **/*.jpg; do exif --remove -o $f $f; done | grep
> 'Wrote
>> file' | wc -l # 2277 (1st invocation)
>>
>> for f in **/*.jpg; do exif --remove -o $f $f; done | grep
> 'Wrote
>> file' |
On Mon, Sep 26, 2022 at 09:07:29PM +0200, Emanuel Berg wrote:
> David Wright wrote:
>
> See the first post ...
> >>>
> >>> The OP didn't contain any exif output, only a couple of
> >>> command lines, apparently written in zsh shell
> >>
> >> Look again!
> >
> > Look at it? I'll quote it in f
Curt wrote:
> One "programming" example given on that same Wikipedia page
> was that if you applied an update operation to Lutz
> Mueller's email address in a database (*ich habe
> Kopfschmerzen*!) that same update applied a second or third
> time (ad infinitum) would produce identical results.
Y
David Wright wrote:
See the first post ...
>>>
>>> The OP didn't contain any exif output, only a couple of
>>> command lines, apparently written in zsh shell
>>
>> Look again!
>
> Look at it? I'll quote it in full (attached).
Look more, quote less ...
for f in **/*.jpg; do exif --remo
mick.crane wrote:
>> I have now clarified to the best of my ability the meaning
>> of that word and I think that will help people understand
>> at last why incorrect tech information, actually
>> disinformation at that point, can't be allowed in software
>> documentation. I get it now that this wa
by bendel.debian.org (Postfix) with QMQP
id EF8442074B; Wed, 21 Sep 2022 07:02:38 + (UTC)
[ … ]
Mail-Followup-To: debian-user@lists.debian.org
To: debian-user@lists.debian.org
From: Emanuel Berg
Subject: exif --remove not idempotent, and a Debian man page bug
Date: Wed, 21 Sep 2
On Sunday, September 25, 2022 08:42:57 AM The Wanderer wrote:
> On 2022-09-25 at 08:22, rhkra...@gmail.com wrote:
> > Oops, ignore that previous response ...
> >
> > On second thought, what hede wrote is correct, it is just stated in a
> > way that I wasn't famiiar with (and I haven't had my morni
On 2022-09-25, Emanuel Berg wrote:
> The Wanderer wrote:
>
>> If the nature of operation O is such that objects B and
>> C are guaranteed to always be identical, no matter what
>> object A was, then operation O is categorized as
>> being idempotent.
>
> It has to do with the number of times it is
On 2022-09-26 06:42, Emanuel Berg wrote:
<...>
I have now clarified to the best of my ability the meaning of
that word and I think that will help people understand at last
why incorrect tech information, actually disinformation at
that point, can't be allowed in software documentation. I get
it n
David Wright wrote:
>> See the first post ...
>
> The OP didn't contain any exif output, only a couple of
> command lines, apparently written in zsh shell
Look again!
> The focus of the thread seems to have changed to the meaning
> of a word in the Subject, and an old email address that
> might
On Sun 25 Sep 2022 at 07:52:38 (+0200), Emanuel Berg wrote:
> Greg Wooledge wrote:
> > If I had the first inkling of a clue what an exif tag
> > actually *was* I might try testing it myself. I'm gathering
> > that it has something to do with JPEG images, based on the
> > *.modified.jpeg default out
> rhkramer wrote:
>
> > An operation that produces the same results no matter how
> > many times it is performed.
>
> Yeah, obviously it is a term from math and in practical and
> applied engineering as is programming I thought of
> a definition (not really) like this
>
> - apply once, you get
The Wanderer wrote:
> If the nature of operation O is such that objects B and
> C are guaranteed to always be identical, no matter what
> object A was, then operation O is categorized as
> being idempotent.
It has to do with the number of times it is applied,
abs(x) = abs(abs(x)) = abs..(abs(abs
rhkramer wrote:
> An operation that produces the same results no matter how
> many times it is performed.
Yeah, obviously it is a term from math and in practical and
applied engineering as is programming I thought of
a definition (not really) like this
- apply once, you get the change
- apply t
Am 25.09.2022 14:42, schrieb The Wanderer:
On 2022-09-25 at 08:22, rhkra...@gmail.com wrote:
On second thought, what hede wrote is correct, it is just stated in a
way that I wasn't famiiar with (and I haven't had my morning coffee
yet)
Are you sure?
Meanwhile, I do think my description was
On 2022-09-25 at 08:22, rhkra...@gmail.com wrote:
> Oops, ignore that previous response ...
>
> On second thought, what hede wrote is correct, it is just stated in a
> way that I wasn't famiiar with (and I haven't had my morning coffee
> yet)
Are you sure?
Because it doesn't seem to match my un
Oops, ignore that previous response ...
On second thought, what hede wrote is correct, it is just stated in a way that
I wasn't famiiar with (and I haven't had my morning coffee yet)
Sorry for the noise!
On Sunday, September 25, 2022 07:56:08 AM rhkra...@gmail.com wrote:
> On Saturday, Septemb
On Saturday, September 24, 2022 09:17:31 AM hede wrote:
> "Idempotent" means, that a task with the same input data and the same
> config (for example to remove a tag via exif-tool) results in the same
> output data. Is this the case here?
That is not my understanding of itempotent (nor of Wikipedi
On 2022-09-25 at 01:43, Emanuel Berg wrote:
> The Wanderer wrote:
>>> There should be no history entries in the man pages that
>>> relates to practical aspects that are no
>>> longer operational.
>>
>> The E-mail address doesn't relate to a practical
>> aspect, though.
>
> Ikr? Since it doesn't
Greg Wooledge wrote:
>> The "-o" means: "Write output image to FILE". And it does
>> so, as far as I can see.
>
> The question is whether specifying "-o f f" where the output file
> has the same name as the input file actually overwrites the original
> input file. Another person reported that it
hede wrote:
> "Idempotent" means, that a task with the same input data and
> the same config (for example to remove a tag via exif-tool)
> results in the same output data.
Determinism.
--
underground experts united
https://dataswamp.org/~incal
The Wanderer wrote:
>>> That's maintainership history, with E-mail
>>> addresses attached.
>>
>> There should be no history entries in the man pages that
>> relates to practical aspects that are no
>> longer operational.
>
> The E-mail address doesn't relate to a practical
> aspect, though.
Ikr?
torical information.
Unless you come up with a patch to do this, and maintain it to cope
with upstream modifications, you're at the mercy of the upstream
and, of course, the Author.
> > In the case of the bash(1) page, it's actually followed by a BUG REPORTS
> > section,
On Sat 24 Sep 2022 at 10:43:04 (-0400), Greg Wooledge wrote:
> On Sat, Sep 24, 2022 at 03:17:31PM +0200, hede wrote:
> > Am 21.09.2022 14:46, schrieb Emanuel Berg:
> > > Maybe related to the '-o f f' part as your imagination
> > > tells you ...
> >
> > The "-o" means: "Write output image to FILE".
On Fri 23 Sep 2022 at 16:14:43 (+0200), Emanuel Berg wrote:
> David Wright wrote:
> >> exif(1) which says on line 57 that --remove
> >>
> >> Remove the tag or (if no tag is specified) the entire IFD.
> >>
> >> Only if it does, why is it there the next time to be removed
> >> as well?
> >
> > Ha
On 2022-09-24, Alex King wrote:
>
>
> I've been using Debian as my main OS since 1997 or earlier. I've spent
> 100s of hours reading man pages. Although it's a reasonable assumption
> (since there are a lot of man pages with outdated AUTHORS sections), I
> didn't know the AUTHORS section is s
On Sat, Sep 24, 2022 at 03:17:31PM +0200, hede wrote:
> Am 21.09.2022 14:46, schrieb Emanuel Berg:
> > Maybe related to the '-o f f' part as your imagination
> > tells you ...
>
> The "-o" means: "Write output image to FILE". And it does so, as far as I
> can see.
The question is whether specifyi
Am 21.09.2022 14:46, schrieb Emanuel Berg:
I don't know what the intended behaviof of "exif --remove -o
file file" is. I'm imagining [...]
exif(1) which says on line 57 that --remove
Remove the tag or (if no tag is specified) the entire IFD.
"Idempotent" means, that a task with the same in
got a reference to that somewhere? After all (some) man pages
have a HISTORY section for historical information.
In the case of the bash(1) page, it's actually followed by a BUG REPORTS
section, telling you how to submit bug reports to the upstream maintainer.
That's not common in man
On 2022-09-23 at 12:02, Emanuel Berg wrote:
> The Wanderer wrote:
>
>> That's maintainership history, with E-mail addresses attached.
>
> There should be no history entries in the man pages that relates to
> practical aspects that are no longer operational.
The E-mail address doesn't relate to
> Brian Fox has not been involved with bash development for
> decades. Nevertheless, removing Brian's email address from
> the AUTHORS section is neither necessary nor desirable.
> Everyone knows it's a historical section.
I think it's wrong to include tech informatio
The Wanderer wrote:
> That's maintainership history, with E-mail
> addresses attached.
There should be no history entries in the man pages that
relates to practical aspects that are no longer operational.
Commands, examples that once worked but are now removed,
options that are obsolete/deprecat
ne knows it's a historical section.
>
> In the case of the bash(1) page, it's actually followed by a BUG
> REPORTS section, telling you how to submit bug reports to the
> upstream maintainer. That's not common in man pages, but clearly not
> unheard of either.
>
&
bash maintainer. Brian Fox has not
been involved with bash development for decades. Nevertheless, removing
Brian's email address from the AUTHORS section is neither necessary nor
desirable. Everyone knows it's a historical section.
In the case of the bash(1) page, it's act
ight © 2002-2012 Thomas Pircher,
>>Dan Fandrich and others.
>>
>> This isn't a contact address for bug reports.
>> It's a historical note.
>
> Indeed, that e-mail belongs to history, which is why it should
> be removed from actively deployed documentation c
Greg Wooledge wrote:
> https://manpages.debian.org/bullseye/exif/exif.1.en.html
>
>AUTHOR
>exif was written by Lutz Mueller
> and numerous contributors.
>This man page is Copyright © 2002-2012 Thomas Pircher,
>Dan Fandrich and others.
>
> This isn&
AUTHOR
exif was written by Lutz Mueller and
numerous contributors. This man page is Copyright © 2002-2012 Thomas
Pircher, Dan Fandrich and others.
This isn't a contact address for bug reports. It's a historical note.
David Wright wrote:
>> But: isn't it still a bug in the distribution man page to
>> refer to mail address that bounces?
>
> I hope the maintainers (Debian's) have better things to do
Are you saying incorrect information in the man pages are OK
in Debian?
> than t
x27;d, let's see what they say.
>
> But: isn't it still a bug in the distribution man page to
> refer to mail address that bounces?
I hope the maintainers (Debian's) have better things to do than trawl
through email addresses in man pages. The man page has its origin
Greg Wooledge wrote:
> According to the package metadata, the Debian maintainer of
> exif is:
OK, cool.
> Maintainer: Debian PhotoTools Maintainers
>
They are CC'd, let's see what they say.
But: isn't it still a bug in the distribution man page to
refer t
ove that from the man page then, i.e. exif(1)
Remove what? Perhaps what you actually want is additional clarity
about how the --remove option (or the -o option) works.
In any case, if you want to file a Debian bug report, see
<https://www.debian.org/Bugs/>.
>From IRC ...
vengeance, you the exif(1) guy here, right, how
can it be it isn't idempotent? I just run it for
every jpg on the HDD and after done, it does the
same thing again upon a 2nd invocation
I'll mail Lutz Mueller as well
fo
Steve McIntyre wrote:
...
> I'm building a new unstable package (2.06-4) right now with Valentin's
> patch applied, and once I've uploaded that I'll do a new bullseye
> package too.
that's great! thank you! :)
songbird
ed from the version in stable
>rather than backported from unstable, but in this case there were no
>intermediate versions in unstable and it was probably thought safer to
>use the package which had been tested in unstable rather than starting
>over and potentially introducing a new bug. That
> On Aug 30, 2022, at 1:12 PM, Casey Deccio wrote:
>
> I am having trouble tracking down a bug in my monitoring setup. It all
> happened when I upgraded the monitored host (host B in my example below) to
> bullseye. Note that Host A is also running bullseye, but the problem
On 9/12/2022 11:36 AM, Tim Woodall wrote:
> On Mon, 12 Sep 2022, David Wright wrote:
>
> >
> > AFAICT it had two months in testing without this problem being
> > hit and reported.
> >
>
> Unfortunately, g-x-h is probably mostly used on stable or oldstable with
> guests running testing.
>
> I'm not
ut in this case there were no
intermediate versions in unstable and it was probably thought safer to
use the package which had been tested in unstable rather than starting
over and potentially introducing a new bug. That probably was even true,
as the problem was identified during the test period o
have been higher.
I think in this case the package was already present in testing and
stable-proposed-updates before the bug was found. It was reported as
"grave" and bounced between that and "serious".
No, it wasn't; as far as I can tell, the bug didn't become &
On Mon, 12 Sep 2022, David Wright wrote:
On Mon 12 Sep 2022 at 14:20:59 (+0100), Tim Woodall wrote:
The same version also went to oldstable - where it turns out it works
fine - so I can see how it could be missed but this was a bug that I
feel would have, if necessary, justified delaying the
sense. "Should bugs make it into Debian releases"?
> >
> > Ah, sorry, I think I misunderstood - you are literally asking if the
> > presence of a severity "serious" bug in Grub should have prevented
> > the whole 11.5 point release happening?
> >
&
he package was already present in testing and
stable-proposed-updates before the bug was found. It was reported as
"grave" and bounced between that and "serious".
Also I am not sure if there are the same processes around this for
packages going in to stable-proposed-updates. Th
On Mon, Sep 12, 2022 at 02:20:59PM +0100, Tim Woodall wrote:
Agreed. While I tend to try to file bugs at the lowest severity that can
be justified, I know that others go the other way. This is one I'd
probably have filed as Grave or even Critical. (I see it's now been
bumped to Grave)
If it's s
On Mon, 12 Sep 2022, David wrote:
On Mon, 12 Sept 2022 at 23:21, Tim Woodall wrote:
It just felt wrong to me that this bug (and version bump of the
package) could go to stable without someone at least acknowleging the
bug. AFAICT there's no fundamental reason it needed to go out. If i
"Should bugs make it into Debian releases"?
> >
> > Ah, sorry, I think I misunderstood - you are literally asking if the
> > presence of a severity "serious" bug in Grub should have prevented
> > the whole 11.5 point release happening?
> >
> > I don&#
u are literally asking if the
presence of a severity "serious" bug in Grub should have prevented
the whole 11.5 point release happening?
I don't know. The only documentation I can find on the matter is
about full Debian releases and even that says the bugs would have to
be apmrked &q
resence of a severity "serious" bug in Grub should have prevented
the whole 11.5 point release happening?
I don't know. The only documentation I can find on the matter is
about full Debian releases and even that says the bugs would have to
be apmrked "release-critical" (RC) to
On Sun, Sep 11, 2022 at 09:23:17PM +0100, Tim Woodall wrote:
> Should https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017944 have
> made it into debian 11.5? I thought serious bugs shouldn't make it into
> stable?
I'm trying to read your email charitably in the sense that yo
On Mon 12 Sep 2022 at 03:36:46 (+0100), Tim Woodall wrote:
> On Sun, 11 Sep 2022, Greg Wooledge wrote:
> > On Sun, Sep 11, 2022 at 09:23:17PM +0100, Tim Woodall wrote:
> > > Should https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017944 have
> > > made it into debian 1
On Sun, 11 Sep 2022, Greg Wooledge wrote:
On Sun, Sep 11, 2022 at 09:23:17PM +0100, Tim Woodall wrote:
Should https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017944 have
made it into debian 11.5? I thought serious bugs shouldn't make it into
stable?
Bugs have to be discovered and rep
On Sun, Sep 11, 2022 at 09:23:17PM +0100, Tim Woodall wrote:
> Should https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017944 have
> made it into debian 11.5? I thought serious bugs shouldn't make it into
> stable?
Bugs have to be discovered and reported. If nobody found t
Should https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017944 have
made it into debian 11.5? I thought serious bugs shouldn't make it into
stable?
I'm not sure this should be merely serious, it broke absolutely
everything for me and took me a while to track down.
Although the
1.3.0-5) 11.3.0, GNU
ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC
Debian 5.18.16-1 (2022-08-10)
The kernel running is from backports, I assume.
Kernels from backports may function different than release packages. You
can test whether it is a kerl bug or not, with insta
On 9/10/22 19:46, Maximiliano Estudies wrote:
Hi,
I seem to have hit a bug with the wireless card driver of my laptop.
This happened twice already, my laptop became unresponsive and I
couldn't issue any sudo commands. After hard rebooting the laptop I
see this entries in the syslog:
Sep
Hi,
I seem to have hit a bug with the wireless card driver of my laptop.
This happened twice already, my laptop became unresponsive and I
couldn't issue any sudo commands. After hard rebooting the laptop I
see this entries in the syslog:
Sep 10 14:51:50 user-thinkpad kernel: mt7921e :03
On Thu, Sep 08, 2022 at 06:22:47PM -0400, José Eduardo Niño wrote:
> Hola. Soy José Niño.
Hola, José
esta lista comunica en inglés. Por consecuencia, la mayoría aquí
no podrá ayudarte.
En caso que prefieras comunicar en castellano: hay una lista en
castellano por aquí:
https://lists.debian.or
Hola. Soy José Niño.
Tengo un problema particular con el hardware de mi computadora,
específicamente con la ranura lectora de memorias SD y microSD.
Con Debian 11.0 funciona perfectamente. Pero, al actualizar con apt upgrade
comienza a fallar.
Con Debian 11.4, al insertar la memoria SD en la ranu
dress by inserting
a space after the @ in the debian-user address.
I forgot about that, clicked send, and the email actually got sent, but the
From: was shown as "Undisclosed recipients".
I don't know whether I should consider that a bug or a feature ;-) But I'll
disable e
> On Aug 30, 2022, at 1:40 PM, Nicholas Geovanis wrote:
>
> When you run check_dns by hand on Host B, you don't say who you are logged-in
> as. That can make a difference. Nagios runs its scripts in a known
> environment which may be different than you expect.
>
Thanks for the question. I
On Tue, Aug 30, 2022, 2:13 PM Casey Deccio wrote:
> Hi all,
>
> I am having trouble tracking down a bug in my monitoring setup. It all
> happened when I upgraded the monitored host (host B in my example below) to
> bullseye. Note that Host A is also running bullseye, but the p
Hi all,
I am having trouble tracking down a bug in my monitoring setup. It all
happened when I upgraded the monitored host (host B in my example below) to
bullseye. Note that Host A is also running bullseye, but the problem didn't
show itself until Host B was upgraded.
Here is the
On 05/08/2022 00:35, Mid Mes Fair wrote:
There is a big bug in auto update in debian 11.
I have turned off the auto checking feature but it still checking and
appear on the notification section in the software
ok.
--
With kindest regards, Piotr.
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal
On Thu, Aug 4, 2022 at 7:51 PM Mid Mes Fair wrote:
> There is a big bug in auto update in debian 11.
> I have turned off the auto checking feature but it still checking and
> appear on the notification section in the software
>
We need more info. To start with:
What Desktop Environ
Richmond writes:
> This bug:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895378
>
> sky2: sky2: did not recover correctly after waking up from S3
>
> seems to be fixed on Ubuntu here:
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798921
>
&g
Hi list,
I've been having a problem with reading local email (like Cron reports
etc.) and I tracked it down to either Evolution or WebKitWebProcess.
I've opened bugs with both and have been talking with the Evolution
mailing list. Milan Crha from that list had me run some backtraces and
all he can
Hi,
Description of problem:
After suspend only one screen activates (dual screen system) and the mouse
seems to be unresponsive.
Basic System
Using AMD cards (Radeon 5600XT and 5500XTY)
My system is setup as a mult-seat system with one seat having two monitors
and the other with one monitor.
Usin
Anders Andersson (12022-05-04):
> On this note, I've always found it annoying that debian (and likely
> others) don't put /sbin in the normal user's $PATH. A lot of the tools
> there have uses other than modifying the system.
I have to unpack Zip files rather often, I use unzip in command-line. It
On Wed, May 04, 2022 at 07:04:52AM -0600, Charles Curley wrote:
> On Wed, 4 May 2022 05:23:31 +0200
> Anders Andersson wrote:
>
> > On this note, I've always found it annoying that debian (and likely
> > others) don't put /sbin in the normal user's $PATH. A lot of the tools
> > there have uses ot
On Wed, 4 May 2022 05:23:31 +0200
Anders Andersson wrote:
> On this note, I've always found it annoying that debian (and likely
> others) don't put /sbin in the normal user's $PATH. A lot of the tools
> there have uses other than modifying the system.
It can be annoying, but for good reason. In
On Wed, May 04, 2022 at 05:23:31AM +0200, Anders Andersson wrote:
[on sbin]
> On this note, I've always found it annoying that debian (and likely
> others) don't put /sbin in the normal user's $PATH. A lot of the tools
> there have uses other than modifying the system.
I've grown accustomed to t
On Mon, May 2, 2022 at 8:19 PM wrote:
> On Mon, May 02, 2022 at 07:58:12PM +0200, Michael Lange wrote:
> > On Mon, 2 May 2022 10:17:06 -0500
> > Richard Owlett wrote:
> > > I'm using Debian 10.7 with MATE DE [will be updated later this week]
> > > The machine is a Lenovo T510 and is setup to logi
On Mon, May 02, 2022 at 07:58:12PM +0200, Michael Lange wrote:
> Hi,
>
> On Mon, 2 May 2022 10:17:06 -0500
> Richard Owlett wrote:
>
> > I'm using Debian 10.7 with MATE DE [will be updated later this week]
> > The machine is a Lenovo T510 and is setup to login as either "richard"
> > or "root".
Hi,
On Mon, 2 May 2022 10:17:06 -0500
Richard Owlett wrote:
> I'm using Debian 10.7 with MATE DE [will be updated later this week]
> The machine is a Lenovo T510 and is setup to login as either "richard"
> or "root".
>
> If logged in as "richard" I can execute su {+ password} and receive a
>
on its size, it decides where it's going to write it,
> ie which block group. Only then does it create the file's inode,
> so that it can keep file contents and inode close together.
That actually makes sense. It would be surprising behaviour,
but at least whithin reach; whether it
On Mon, May 02, 2022 at 03:43:41PM +, Andrew M.A. Cater wrote:
> Not bug - feature.
I disagree. Strongly. It is a CHANGE, but it is not a feature.
> See also su -
>
> It's in the release notes, I'm fairly sure.
It's also at <https://wiki.debian.org/NewInBust
" I can execute su {+ password} and receive a prompt
> indicating I'm "root".
>
> However if I then enter "update-grub", the response is
> "bash: update-grub: command not found"
> as if I were the unprivileged user "richard".
>
Il 02/05/22 17:17, Richard Owlett ha scritto:
If logged in as "richard" I can execute su {+ password} and receive a
prompt indicating I'm "root".
"bash: update-grub: command not found"
Bug?
No, it's only an effect of the PATH variable. Try "su -".
root".
However if I then enter "update-grub", the response is
"bash: update-grub: command not found"
as if I were the unprivileged user "richard".
All is normal if I had initially been "root" or had become "root" via
System -> Log Out richard .
Bug?
ndering whether the data are transferred from the VFS to ext4
> necessarily within the same openat system call or could just be kept
> in the VFS as long as they are not needed elsewhere, i.e. the VFS
> behaving like a cache. In the latter case, since the VFS doesn't
> have a notion
On Mon, May 02, 2022 at 01:10:04AM +0200, Vincent Lefevre wrote:
> On 2022-04-30 14:06:53 +0200, to...@tuxteam.de wrote:
[...]
> > It sure looks like a bug. But it would be a bug at a spot where one would
> > expect that it should have bitten oodles of other people by now, so t
ving like a cache. In the latter case, since the VFS doesn't
> have a notion of birth timestamp (from the code I've read), a bug
> in the VFS code could explain the behavior I had observed. This is
> the only explanation I could have.
At this point, you should seriously consider
in the VFS as long as they are not needed elsewhere, i.e. the VFS
behaving like a cache. In the latter case, since the VFS doesn't
have a notion of birth timestamp (from the code I've read), a bug
in the VFS code could explain the behavior I had
On 2022-04-30 14:06:53 +0200, to...@tuxteam.de wrote:
> On Sat, Apr 30, 2022 at 10:33:34AM +0200, Thomas Schmitt wrote:
> > I understand that Vincent Lefevre suspects these discrepancies to be a bug
> > in the ext4 driver. I rather suspect that ext4 is ok and that we observe
>
Hi,
Curt wrote:
> What does the following mean, then, in that light:
> Because of delayed allocation and other performance optimizations, ext4's
> behavior of writing files to disk is different from ext3. In ext4, when a
> program writes to the file system, it is not guaranteed to be on-disk
On Sat, Apr 30, 2022 at 12:31:07PM -, Curt wrote:
> On 2022-04-30, Thomas Schmitt wrote:
> >
> > Indeed. With normal filesystem operations there should be no need to call
> > something like sync(2) in order to get a consistent representation of the
> > current filesystem state.
> >
>
> What d
On 2022-04-30, Thomas Schmitt wrote:
>
> Indeed. With normal filesystem operations there should be no need to call
> something like sync(2) in order to get a consistent representation of the
> current filesystem state.
>
What does the following mean, then, in that light:
Because of delayed allo
th via the operating
system facilities is the cache's view. The disk's view will become
consistent with that at some time in the future (at least we hope
that).
[...]
> I understand that Vincent Lefevre suspects these discrepancies to be a bug
> in the ext4 driver. I rather susp
401 - 500 of 5957 matches
Mail list logo
