Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #24539 > unrolled thread

Sometiomes I really LOVE linux.

Back to article view | Back to comp.os.linux.misc

Contents

  Sometiomes I really LOVE linux. The Natural Philosopher <tnp@invalid.invalid> - 2018-09-24 19:29 +0100
    Re: Sometiomes I really LOVE linux. Robert Heller <heller@deepsoft.com> - 2018-09-24 15:14 -0500
      Re: Sometiomes I really LOVE linux. Bobbie Sellers <bliss@mouse-potato.com> - 2018-09-24 14:01 -0700
        Re: Sometiomes I really LOVE linux. Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2018-09-24 21:27 +0000
          Re: Sometiomes I really LOVE linux. "Carlos E. R." <robin_listas@es.invalid> - 2018-09-24 22:49 -0400
            Re: Sometiomes I really LOVE linux. Richard Kettlewell <invalid@invalid.invalid> - 2018-09-25 09:08 +0100
            Re: Sometiomes I really LOVE linux. Rich <rich@example.invalid> - 2018-09-25 11:51 +0000
              Re: Sometiomes I really LOVE linux. Richard Kettlewell <invalid@invalid.invalid> - 2018-09-25 14:45 +0100
                Re: Sometiomes I really LOVE linux. Rich <rich@example.invalid> - 2018-09-25 20:22 +0000
                  Re: Sometiomes I really LOVE linux. Richard Kettlewell <invalid@invalid.invalid> - 2018-09-26 08:32 +0100
            Re: Sometiomes I really LOVE linux. Robert Heller <heller@deepsoft.com> - 2018-09-25 08:34 -0500
              Re: Sometiomes I really LOVE linux. Eli the Bearded <*@eli.users.panix.com> - 2018-09-25 15:28 +0000
                Re: Sometiomes I really LOVE linux. Robert Heller <heller@deepsoft.com> - 2018-09-25 11:21 -0500
                  Re: Sometiomes I really LOVE linux. Eli the Bearded <*@eli.users.panix.com> - 2018-09-25 21:26 +0000
                    Re: Sometiomes I really LOVE linux. Robert Heller <heller@deepsoft.com> - 2018-09-25 19:06 -0500
                Re: Sometiomes I really LOVE linux. Rich <rich@example.invalid> - 2018-09-25 20:33 +0000
                  Re: Sometiomes I really LOVE linux. Eli the Bearded <*@eli.users.panix.com> - 2018-09-25 23:41 +0000
                    Re: Sometiomes I really LOVE linux. Rich <rich@example.invalid> - 2018-09-26 00:51 +0000
    Re: Sometiomes I really LOVE linux. jrg <jeff.g.group@att.net> - 2018-09-24 14:33 -0700
      Re: Sometiomes I really LOVE linux. Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2018-09-24 21:59 +0000

#24539 — Sometiomes I really LOVE linux.

I am you see tidying up my video collection by using handbrake to trim 
the videos to their actual size rather than the form thay came in, 
suuround by 'black space'  And crop off station ids where they are on 
recirded materail but 'off screen'

So I set up a batch in Handbrake, then went and did something else, then 
started deleting all the converted files - files that had .mp4 
extensions and also .m4v extensions.

Then I realised I had just deleted the source file of the movie 
currently being converted.

Handbrake, which had the file open, didnt even blink.

Linux of course wont ACTUALLY delete the file until is is closed by all 
accessing it..

A fundamental safeguard on an OS derived from multiuser Unix...

-- 
“But what a weak barrier is truth when it stands in the way of an 
hypothesis!”

Mary Wollstonecraft

[toc] | [next] | [standalone]

#24541

At Mon, 24 Sep 2018 19:29:43 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:

> 
> 
> I am you see tidying up my video collection by using handbrake to trim 
> the videos to their actual size rather than the form thay came in, 
> suuround by 'black space'  And crop off station ids where they are on 
> recirded materail but 'off screen'
> 
> So I set up a batch in Handbrake, then went and did something else, then 
> started deleting all the converted files - files that had .mp4 
> extensions and also .m4v extensions.
> 
> Then I realised I had just deleted the source file of the movie 
> currently being converted.
> 
> Handbrake, which had the file open, didnt even blink.
> 
> Linux of course wont ACTUALLY delete the file until is is closed by all 
> accessing it..

Linux never really (actually) deletes files. "rm" just "unlinks" them (removes
the *directory entry*) (the kernel call is "unlink", there is no "delete"
kernel call). The inodes don't get moved to the free list until both of these
states are true:

There are no directory entries pointing at the inodes.

There are no open files pointing at the inodes.

> 
> A fundamental safeguard on an OS derived from multiuser Unix...
> 

Just the right thing to do.

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                        

[toc] | [prev] | [next] | [standalone]

#24542

On 9/24/18 1:14 PM, Robert Heller wrote:
> At Mon, 24 Sep 2018 19:29:43 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:
> 
>>
>>
>> I am you see tidying up my video collection by using handbrake to trim
>> the videos to their actual size rather than the form thay came in,
>> suuround by 'black space'  And crop off station ids where they are on
>> recirded materail but 'off screen'
>>
>> So I set up a batch in Handbrake, then went and did something else, then
>> started deleting all the converted files - files that had .mp4
>> extensions and also .m4v extensions.
>>
>> Then I realised I had just deleted the source file of the movie
>> currently being converted.
>>
>> Handbrake, which had the file open, didnt even blink.
>>
>> Linux of course wont ACTUALLY delete the file until is is closed by all
>> accessing it..
> 
> Linux never really (actually) deletes files. "rm" just "unlinks" them (removes
> the *directory entry*) (the kernel call is "unlink", there is no "delete"
> kernel call). The inodes don't get moved to the free list until both of these
> states are true:
> 
> There are no directory entries pointing at the inodes.
> 
> There are no open files pointing at the inodes.
> 
>>
>> A fundamental safeguard on an OS derived from multiuser Unix...
>>
> 
> Just the right thing to do.
> 
	Only sometimes? I like Linux about 8 days a week.
	
	bliss

-- 
bliss dash SF 4 ever at dslextreme dot com

[toc] | [prev] | [next] | [standalone]

#24543

On 2018-09-24, Bobbie Sellers <bliss@mouse-potato.com> wrote:

> On 9/24/18 1:14 PM, Robert Heller wrote:
>
>> At Mon, 24 Sep 2018 19:29:43 +0100 The Natural Philosopher
>> <tnp@invalid.invalid> wrote:
>> 
>>> I am you see tidying up my video collection by using handbrake to trim
>>> the videos to their actual size rather than the form thay came in,
>>> suuround by 'black space'  And crop off station ids where they are on
>>> recirded materail but 'off screen'
>>>
>>> So I set up a batch in Handbrake, then went and did something else, then
>>> started deleting all the converted files - files that had .mp4
>>> extensions and also .m4v extensions.
>>>
>>> Then I realised I had just deleted the source file of the movie
>>> currently being converted.
>>>
>>> Handbrake, which had the file open, didnt even blink.
>>>
>>> Linux of course wont ACTUALLY delete the file until is is closed by all
>>> accessing it..
>> 
>> Linux never really (actually) deletes files. "rm" just "unlinks" them
>> (removes the *directory entry*) (the kernel call is "unlink", there is
>> no "delete" kernel call). The inodes don't get moved to the free list
>> until both of these states are true:
>> 
>> There are no directory entries pointing at the inodes.
>> 
>> There are no open files pointing at the inodes.
>> 
>>> A fundamental safeguard on an OS derived from multiuser Unix...
>> 
>> Just the right thing to do.
>> 
> 	Only sometimes? I like Linux about 8 days a week.

Which is about how much I hate Windows - especially its damned file system,
including its obsession with exclusive file locks.

One of the most FA'd of Qs in Windows discussion groups is:
"How do I update the executable file for a running program?"
This is met by a flood of answers describing increasingly
convoluted hacks - usually involving at least one reboot -
culminating in the conclusion: "You can't."  Under Linux
it's trivial.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

[toc] | [prev] | [next] | [standalone]

#24546

On 24/09/2018 17.27, Charlie Gibbs wrote:
> On 2018-09-24, Bobbie Sellers <bliss@mouse-potato.com> wrote:
> 
>> On 9/24/18 1:14 PM, Robert Heller wrote:
>>
>>> At Mon, 24 Sep 2018 19:29:43 +0100 The Natural Philosopher
>>> <tnp@invalid.invalid> wrote:
>>>
>>>> I am you see tidying up my video collection by using handbrake to trim
>>>> the videos to their actual size rather than the form thay came in,
>>>> suuround by 'black space'  And crop off station ids where they are on
>>>> recirded materail but 'off screen'
>>>>
>>>> So I set up a batch in Handbrake, then went and did something else, then
>>>> started deleting all the converted files - files that had .mp4
>>>> extensions and also .m4v extensions.
>>>>
>>>> Then I realised I had just deleted the source file of the movie
>>>> currently being converted.
>>>>
>>>> Handbrake, which had the file open, didnt even blink.
>>>>
>>>> Linux of course wont ACTUALLY delete the file until is is closed by all
>>>> accessing it..
>>>
>>> Linux never really (actually) deletes files. "rm" just "unlinks" them
>>> (removes the *directory entry*) (the kernel call is "unlink", there is
>>> no "delete" kernel call). The inodes don't get moved to the free list
>>> until both of these states are true:
>>>
>>> There are no directory entries pointing at the inodes.
>>>
>>> There are no open files pointing at the inodes.
>>>
>>>> A fundamental safeguard on an OS derived from multiuser Unix...
>>>
>>> Just the right thing to do.
>>>
>> 	Only sometimes? I like Linux about 8 days a week.
> 
> Which is about how much I hate Windows - especially its damned file system,
> including its obsession with exclusive file locks.
> 
> One of the most FA'd of Qs in Windows discussion groups is:
> "How do I update the executable file for a running program?"
> This is met by a flood of answers describing increasingly
> convoluted hacks - usually involving at least one reboot -
> culminating in the conclusion: "You can't."  Under Linux
> it's trivial.

Well, you can't because Windows by design removes from RAM code sections
of a program that are not used at the moment, and loads them from the
file.exe again when needed. If the exe file gets changed, the
application would crash.

Windows thus impedes replacing an exe that is running, obviously. It
would be a bad thing in Windows to change the file.

Simply different design, not better nor worse. Different, with different
set of pros and againsts.


Say... but the program could maintain a pointer to the old file and use
it, while the disk lists a new version. Yes... but then instances of the
programs loaded at different instants would behave differently, possibly
causing strange errors. Beside requiring a different filesystem design.

So, no :-)

-- 
Cheers,
       Carlos E.R.

[toc] | [prev] | [next] | [standalone]

#24547

"Carlos E. R." <robin_listas@es.invalid> writes:
> On 24/09/2018 17.27, Charlie Gibbs wrote:
>> One of the most FA'd of Qs in Windows discussion groups is:
>> "How do I update the executable file for a running program?"
>> This is met by a flood of answers describing increasingly
>> convoluted hacks - usually involving at least one reboot -
>> culminating in the conclusion: "You can't."  Under Linux
>> it's trivial.
>
> Well, you can't because Windows by design removes from RAM code
> sections of a program that are not used at the moment, and loads them
> from the file.exe again when needed.  If the exe file gets changed,
> the application would crash.

Modern Unix platforms all do the same, so that explanation doesn’t work.

> Windows thus impedes replacing an exe that is running, obviously. It
> would be a bad thing in Windows to change the file.
>
> Simply different design, not better nor worse. Different, with different
> set of pros and againsts.
>
>
> Say... but the program could maintain a pointer to the old file and use
> it, while the disk lists a new version. Yes... but then instances of the
> programs loaded at different instants would behave differently, possibly
> causing strange errors.

Yes, and that’s an issue on Unix too.

> Beside requiring a different filesystem design.

Not really. Renaming the old executable to a new name would be
sufficient, if the filesystem can’t manage anonymous files for some
reason (I suspect in fact that it can).

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#24548

Carlos E. R. <robin_listas@es.invalid> wrote:
> On 24/09/2018 17.27, Charlie Gibbs wrote:
>> One of the most FA'd of Qs in Windows discussion groups is: "How do
>> I update the executable file for a running program?" This is met by
>> a flood of answers describing increasingly convoluted hacks -
>> usually involving at least one reboot - culminating in the
>> conclusion: "You can't." Under Linux it's trivial.
> 
> Well, you can't because Windows by design removes from RAM code
> sections of a program that are not used at the moment, and loads them
> from the file.exe again when needed.

As does Linux, and this is not the reason why the executable can't be
swapped on windows but can on linux.

> If the exe file gets changed, the application would crash.

Not on Linux, but yes, due to the windows design it would on windows.

> Windows thus impedes replacing an exe that is running, obviously. It
> would be a bad thing in Windows to change the file.

Windows impedes any change to a file that is open in any way (can't
rename, can't delete, can't change, etc.), which includes the subset of
exe files that are open because the code contained therein is running. 
It is windows mandatory file locking in action.

> Say... but the program could maintain a pointer to the old file and use
> it, while the disk lists a new version.

Which is how it works on Linux, and is why Linux will let you delete
and create a new executable while the running program continues,
unaware that anything changed.

> Beside requiring a different filesystem design.

And here we have the root cause on windows.  The windows filesystem
design does not allow the feature that Linux's filesystem design does,
so this is the root reason why "you can't do that" is the answer to the
common windows question.

[toc] | [prev] | [next] | [standalone]

#24553

Rich <rich@example.invalid> writes:
> Carlos E. R. <robin_listas@es.invalid> wrote:
>> Say... but the program could maintain a pointer to the old file and use
>> it, while the disk lists a new version.
>
> Which is how it works on Linux, and is why Linux will let you delete
> and create a new executable while the running program continues,
> unaware that anything changed.
>
>> Beside requiring a different filesystem design.
>
> And here we have the root cause on windows.  The windows filesystem
> design does not allow the feature that Linux's filesystem design does,

Why do you think that? The WP article on NTFS describes essentially the
same indirection between filenames and contents as found in traditional
Unix filesystems. Even if it was true it would not inherently prevent
running executable being replaced, it would just make it a bit more
complicated.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#24567

Richard Kettlewell <invalid@invalid.invalid> wrote:
> Rich <rich@example.invalid> writes:
>> Carlos E. R. <robin_listas@es.invalid> wrote:
>>> Say... but the program could maintain a pointer to the old file and use
>>> it, while the disk lists a new version.
>>
>> Which is how it works on Linux, and is why Linux will let you delete
>> and create a new executable while the running program continues,
>> unaware that anything changed.
>>
>>> Beside requiring a different filesystem design.
>>
>> And here we have the root cause on windows.  The windows filesystem
>> design does not allow the feature that Linux's filesystem design does,
> 
> Why do you think that? The WP article on NTFS describes essentially the
> same indirection between filenames and contents as found in traditional
> Unix filesystems. Even if it was true it would not inherently prevent
> running executable being replaced, it would just make it a bit more
> complicated.

Ok, then reword my statement to: "the subset of capabilities of the
NTFS filesystem design exposed by windows to windows programs does not
allow on windows of the feature that Linux exposes to Linux
executables".

[toc] | [prev] | [next] | [standalone]

#24575

Rich <rich@example.invalid> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> Rich <rich@example.invalid> writes:
>>> Carlos E. R. <robin_listas@es.invalid> wrote:
>>>> Beside requiring a different filesystem design.
>>>
>>> And here we have the root cause on windows.  The windows filesystem
>>> design does not allow the feature that Linux's filesystem design does,
>> 
>> Why do you think that? The WP article on NTFS describes essentially the
>> same indirection between filenames and contents as found in traditional
>> Unix filesystems. Even if it was true it would not inherently prevent
>> running executable being replaced, it would just make it a bit more
>> complicated.
>
> Ok, then reword my statement to: "the subset of capabilities of the
> NTFS filesystem design exposed by windows to windows programs does not
> allow on windows of the feature that Linux exposes to Linux
> executables".

It’s equally true that “the subset of capabilities of the x86 ISA
exposed by windows programs does not allow etc etc etc”. You can cram
any low-level component you like into an explanation but it doesn’t
really add anything to it.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#24551

At Mon, 24 Sep 2018 22:49:38 -0400 "Carlos E. R." <robin_listas@es.invalid> wrote:

> 
> On 24/09/2018 17.27, Charlie Gibbs wrote:
> > On 2018-09-24, Bobbie Sellers <bliss@mouse-potato.com> wrote:
> > 
> >> On 9/24/18 1:14 PM, Robert Heller wrote:
> >>
> >>> At Mon, 24 Sep 2018 19:29:43 +0100 The Natural Philosopher
> >>> <tnp@invalid.invalid> wrote:
> >>>
> >>>> I am you see tidying up my video collection by using handbrake to trim
> >>>> the videos to their actual size rather than the form thay came in,
> >>>> suuround by 'black space'  And crop off station ids where they are on
> >>>> recirded materail but 'off screen'
> >>>>
> >>>> So I set up a batch in Handbrake, then went and did something else, then
> >>>> started deleting all the converted files - files that had .mp4
> >>>> extensions and also .m4v extensions.
> >>>>
> >>>> Then I realised I had just deleted the source file of the movie
> >>>> currently being converted.
> >>>>
> >>>> Handbrake, which had the file open, didnt even blink.
> >>>>
> >>>> Linux of course wont ACTUALLY delete the file until is is closed by all
> >>>> accessing it..
> >>>
> >>> Linux never really (actually) deletes files. "rm" just "unlinks" them
> >>> (removes the *directory entry*) (the kernel call is "unlink", there is
> >>> no "delete" kernel call). The inodes don't get moved to the free list
> >>> until both of these states are true:
> >>>
> >>> There are no directory entries pointing at the inodes.
> >>>
> >>> There are no open files pointing at the inodes.
> >>>
> >>>> A fundamental safeguard on an OS derived from multiuser Unix...
> >>>
> >>> Just the right thing to do.
> >>>
> >> 	Only sometimes? I like Linux about 8 days a week.
> > 
> > Which is about how much I hate Windows - especially its damned file system,
> > including its obsession with exclusive file locks.
> > 
> > One of the most FA'd of Qs in Windows discussion groups is:
> > "How do I update the executable file for a running program?"
> > This is met by a flood of answers describing increasingly
> > convoluted hacks - usually involving at least one reboot -
> > culminating in the conclusion: "You can't."  Under Linux
> > it's trivial.
> 
> Well, you can't because Windows by design removes from RAM code sections
> of a program that are not used at the moment, and loads them from the
> file.exe again when needed. If the exe file gets changed, the
> application would crash.

Linux is not really any different, except *Linux* *NEVER* "deletes" a *file*. 
It only ever reclaims "orphaned" inodes.  If you rm a running program file 
under Linux, you are only removing the directory entry.  The kernel's process 
header retains an open file descriptor pointing at the program file's inodes.  
The kernel can still continue to page in the RO parts of the program as 
needed.  Meanwhile you can create a new program file under the "old" name.  
Later when the program finishes (or is killed, or whatever), the old inodes 
get reclaimed and when the program is next started, it uses the new verson.

> 
> Windows thus impedes replacing an exe that is running, obviously. It
> would be a bad thing in Windows to change the file.
> 
> Simply different design, not better nor worse. Different, with different
> set of pros and againsts.
> 
> 
> Say... but the program could maintain a pointer to the old file and use
> it, while the disk lists a new version. Yes... but then instances of the
> programs loaded at different instants would behave differently, possibly
> causing strange errors. Beside requiring a different filesystem design.
> 
> So, no :-)
> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                                               

[toc] | [prev] | [next] | [standalone]

#24555

In comp.os.linux.misc, Robert Heller  <heller@deepsoft.com> wrote:
> "Carlos E. R." <robin_listas@es.invalid> wrote:
>> of a program that are not used at the moment, and loads them from the
>> file.exe again when needed. If the exe file gets changed, the
>> application would crash.
> Linux is not really any different, except *Linux* *NEVER* "deletes" a
> *file*. 
...
> The kernel can still continue to page in the RO parts of the program as 
> needed.  Meanwhile you can create a new program file under the "old" name.  
> Later when the program finishes (or is killed, or whatever), the old inodes 
> get reclaimed and when the program is next started, it uses the new verson.

And if you don't do that rename step, and edit a program, unpredictable
things happen. It's easiest to do with scripts. In the case of Perl, the
interpreter reads the whole thing and then runs, pretty safe. In the
case of Bash, it reads it line by line, so if the script changes
underneath it, it will likely read the next line from the wrong spot.

Elijah
------
this is general unix stuff, not linux specific

[toc] | [prev] | [next] | [standalone]

#24561

At Tue, 25 Sep 2018 15:28:00 +0000 (UTC) Eli the Bearded <*@eli.users.panix.com> wrote:

> 
> In comp.os.linux.misc, Robert Heller  <heller@deepsoft.com> wrote:
> > "Carlos E. R." <robin_listas@es.invalid> wrote:
> >> of a program that are not used at the moment, and loads them from the
> >> file.exe again when needed. If the exe file gets changed, the
> >> application would crash.
> > Linux is not really any different, except *Linux* *NEVER* "deletes" a
> > *file*. 
> ...
> > The kernel can still continue to page in the RO parts of the program as 
> > needed.  Meanwhile you can create a new program file under the "old" name.  
> > Later when the program finishes (or is killed, or whatever), the old inodes 
> > get reclaimed and when the program is next started, it uses the new verson.
> 
> And if you don't do that rename step, and edit a program, unpredictable

Rename (mv) is really a link (to the new name) and an unlink (remove the old
name). If there is no need to keep the old program, an rm (unlink) is enough.

> things happen. It's easiest to do with scripts. In the case of Perl, the
> interpreter reads the whole thing and then runs, pretty safe. In the
> case of Bash, it reads it line by line, so if the script changes
> underneath it, it will likely read the next line from the wrong spot.
> 
> Elijah
> ------
> this is general unix stuff, not linux specific
>                                                                                            

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                   

[toc] | [prev] | [next] | [standalone]

#24571

In comp.os.linux.misc, Robert Heller  <heller@deepsoft.com> wrote:
> Eli the Bearded <*@eli.users.panix.com> wrote:
>> And if you don't do that rename step, and edit a program, unpredictable
> Rename (mv) is really a link (to the new name) and an unlink (remove the old
> name). If there is no need to keep the old program, an rm (unlink) is enough.

'mv', to the same filesystem, is atomic unlike the process you describe
above. 'mv' to a different filesystem is copy + unlink, and not supported
by all versions of 'mv'. (I forget if the process of overwriting a name
is atomic, if 'mv old new' is run while "new" exists, but I'm pretty
sure it is. In any case, rename to the same filesystem is just the
rename() system call, see rename(2). )

I note that I provided an example of something that can't happen in
Windows, editing a program while it is running and an example of a type
of program that will be confused by that, and you have ignored that and
discussed the semantics of what a "rename" is.

>> things happen. It's easiest to do with scripts. In the case of Perl, the
>> interpreter reads the whole thing and then runs, pretty safe. In the
>> case of Bash, it reads it line by line, so if the script changes
>> underneath it, it will likely read the next line from the wrong spot.

To reiterate my point: running programs may have an open filepointer to
read instructions even after startup. If the code in the program changes
after startup, the running program will have undefined behavior, and
possibly fail. When you rename the file, the open file pointer stays
with the original inode, and a new version will be completely isolated.

Elijah
------
why he renames /usr/lib/firefox when installing a new one by hand

[toc] | [prev] | [next] | [standalone]

#24573

At Tue, 25 Sep 2018 21:26:23 +0000 (UTC) Eli the Bearded <*@eli.users.panix.com> wrote:

> 
> In comp.os.linux.misc, Robert Heller  <heller@deepsoft.com> wrote:
> > Eli the Bearded <*@eli.users.panix.com> wrote:
> >> And if you don't do that rename step, and edit a program, unpredictable
> > Rename (mv) is really a link (to the new name) and an unlink (remove the old
> > name). If there is no need to keep the old program, an rm (unlink) is enough.
> 
> 'mv', to the same filesystem, is atomic unlike the process you describe

Yes, but logically it is like a link/unlink.  Effectively the mv just connects 
the inodes to a fresh directory entry (file name).  This does not effect the 
open file.


> above. 'mv' to a different filesystem is copy + unlink, and not supported
> by all versions of 'mv'. (I forget if the process of overwriting a name
> is atomic, if 'mv old new' is run while "new" exists, but I'm pretty
> sure it is. In any case, rename to the same filesystem is just the
> rename() system call, see rename(2). )


> 
> I note that I provided an example of something that can't happen in
> Windows, editing a program while it is running and an example of a type
> of program that will be confused by that, and you have ignored that and
> discussed the semantics of what a "rename" is.
> 
> >> things happen. It's easiest to do with scripts. In the case of Perl, the
> >> interpreter reads the whole thing and then runs, pretty safe. In the
> >> case of Bash, it reads it line by line, so if the script changes
> >> underneath it, it will likely read the next line from the wrong spot.
> 
> To reiterate my point: running programs may have an open filepointer to
> read instructions even after startup. If the code in the program changes
> after startup, the running program will have undefined behavior, and
> possibly fail. When you rename the file, the open file pointer stays
> with the original inode, and a new version will be completely isolated.
> 
> Elijah
> ------
> why he renames /usr/lib/firefox when installing a new one by hand
>                                                                  

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                               

[toc] | [prev] | [next] | [standalone]

#24568

Eli the Bearded <*@eli.users.panix.com> wrote:
> In comp.os.linux.misc, Robert Heller  <heller@deepsoft.com> wrote:
>> "Carlos E. R." <robin_listas@es.invalid> wrote:
>>> of a program that are not used at the moment, and loads them from the
>>> file.exe again when needed. If the exe file gets changed, the
>>> application would crash.
>> Linux is not really any different, except *Linux* *NEVER* "deletes" a
>> *file*. 
> ...
>> The kernel can still continue to page in the RO parts of the program as 
>> needed.  Meanwhile you can create a new program file under the "old" name.  
>> Later when the program finishes (or is killed, or whatever), the old inodes 
>> get reclaimed and when the program is next started, it uses the new verson.
> 
> And if you don't do that rename step, and edit a program, unpredictable
> things happen.

And?  Editing your swapfile by reaching in and directly changing its
contents while the kernel is using it for swap will also cause
unpredictable things to occur.  Nothing new here.

> It's easiest to do with scripts. In the case of Perl, the interpreter
> reads the whole thing and then runs, pretty safe.  In the case of
> Bash, it reads it line by line, so if the script changes underneath
> it, it will likely read the next line from the wrong spot.

Whether this bites you with bash depends upon how long the script is
and what read buffer size the stdio library on the particular machine
uses.  If the stdio buffer size is larger than the script length,
direct edits to the file would have no effect on the current running
version of the script.  But if the script is longer than the buffer
size, then yes, special magic may start to happen when the next buffer
of data eventually is read in by the stdio library.

[toc] | [prev] | [next] | [standalone]

#24572

In comp.os.linux.misc, Rich  <rich@example.invalid> wrote:
> Eli the Bearded <*@eli.users.panix.com> wrote:
>> And if you don't do that rename step, and edit a program, unpredictable
>> things happen.
> And?  Editing your swapfile by reaching in and directly changing its
> contents while the kernel is using it for swap will also cause
> unpredictable things to occur.  Nothing new here.

Yeah, but it's the other side of the "forced locks coin" that people here
are complaining about in Windows.

Elijah
------
trade-offs each and every decision

[toc] | [prev] | [next] | [standalone]

#24574

Eli the Bearded <*@eli.users.panix.com> wrote:
> In comp.os.linux.misc, Rich  <rich@example.invalid> wrote:
>> Eli the Bearded <*@eli.users.panix.com> wrote:
>>> And if you don't do that rename step, and edit a program, unpredictable
>>> things happen.
>> And?  Editing your swapfile by reaching in and directly changing its
>> contents while the kernel is using it for swap will also cause
>> unpredictable things to occur.  Nothing new here.
> 
> Yeah, but it's the other side of the "forced locks coin" that people here
> are complaining about in Windows.
> ------
> trade-offs each and every decision

This is true.  Myself, I'll take the tradeoff that allows me to shoot
myself in the foot if I want (but I know better not to do so) in order
to gain the other flexibilities of being able to upgrade a running
program/deamon while it is running and with minimal downtime, or of
being able to remove, now, a file (or simply rename it to mark it as
"begun processing"), knowing that something like handbrake (which
started this thread) can continue for the next 8 hours, afterwhich the
file's blocks will also be freed (if the rm option was used) over
having to remember to "delete (or rename) that file 8 hours from now".

I.e., the mandatory locks might preclude one "foot gun" (modify
contents of file in use) but while precluding that one case, it also
precludes multiple other useful use cases (of which the above are but a
few examples) that are not of the "foot gun" type.

It is somewhat like the difference between being treated as an adult
(you know what you are doing, so ok, if you break it you have to put it
back together) vs. a child (we have to protect you from yourself so
you don't hurt yourself).

[toc] | [prev] | [next] | [standalone]

#24544

On 09/24/2018 11:29 AM, The Natural Philosopher wrote:

> I am you see tidying up my video collection by using handbrake to trim
> the videos to their actual size rather than the form thay came in,
> suuround by 'black space'  And crop off station ids where they are on
> recirded materail but 'off screen'

yipes - thought you wouldn't make it through that post :)
tbird spelchek broke?

[toc] | [prev] | [next] | [standalone]

#24545

On 2018-09-24, jrg <jeff.g.group@att.net> wrote:

> On 09/24/2018 11:29 AM, The Natural Philosopher wrote:
>
>> I am you see tidying up my video collection by using handbrake to trim
>> the videos to their actual size rather than the form thay came in,
>> suuround by 'black space'  And crop off station ids where they are on
>> recirded materail but 'off screen'
>
> yipes - thought you wouldn't make it through that post :)
> tbird spelchek broke?

    I have a spelling checker,
    It came with my PC;
    It plainly marks four my revue
    Mistakes I cannot see.
    I've run this poem threw it,
    I'm sure your pleased too no,
    Its letter perfect in it's weigh,
    My checker tolled me sew.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web