Re: How do I eliminate the "recent" entry in the Nautilus file manager?

[Bob Pack]

On Mon, 16 Feb 2015 00:50:33 +0100, Melzzzzz wrote:

>
> Perhaps this can help? :
> http://ubuntuforums.org/showthread.php?t=2154627

Been there. Done that. It all fails for KDE because it's all
for Gnome (I guess).

That forum thread was titled:
"How do you clear the recent files list in nautilus?"

As the title said, at first they thought the guy just wanted
to just "clear" the recent files list (which is not the question at all):
i

Then they said to create a file named: ~/.config/gtk-3.0/settings.ini
And then to populate it with:
[Settings]
gtk-recent-files-max-age=0
gtk-recent-files-limit=0

They said nothing but 0 will work, so, they said it's all or none
but, then the thread indicates that none of that works in
Nautilus after and including Nautilus version 3.8 (and it didn't
work for me).

$ nautilus --version
GNOME nautilus 3.10.1

They said the dconf-editor works (but I already tried that, and
failed):
dconf-editor
go to org->gnome->desktop->privacy
and uncheck the remember-recent-files

This sounds nice, but doesn't have any effect whatsoever.
In fact, the thread's last post references the exact thread
we already used, and failed with, for removing recent files
in Nautilus:
http://askubuntu.com/questions/294901/how-to-disable-recent-files-folder-in-nautilus
How to disable “recent files” folder in Nautilus?

I think the problem is that everyone is expecting Gnome for
some reason, and I have KDE.

Moving on, they said since almost nothing worked for them either:
$ rm ~/.local/share/recently-used.xbel # clear current file history
$ touch ~/.local/share/recently-used.xbel # create a 0-byte history file
$ sudo chattr +i ~/.local/share/recently-used.xbel # make it readonly

They go on to say in 14.04 you can go to:
Settings > Security & Privacy > Files & Applications and check "off"
for "Record file and application usage", but that doesn't even exist
in Kubuntu 14.04 with KDE.

So, basically, nothing works to preserve your privacy in Kubuntu
14.04 with KDE and Recent Files management. Sigh.

Here's a summary:
Method 1: Select all recent files and delete
Why Failed? They come back. This does not remove the Recent Files capability.

Method 2: Exec=sh -c "echo > ~/.local/share/recently-used.xbel"
Why Failed? It comes back.

Method 3: Create a file named: ~/.config/gtk-3.0/settings.ini
gedit ~/.config/gtk-3.0/settings.ini
And then to populate it with:
[Settings]
gtk-recent-files-max-age=0
gtk-recent-files-limit=0

But settings.ini won't work from nautilus 3.8 onward.
$ nautilus --version
GNOME nautilus 3.10.1

Method 4:
$ dconf-editor
dconf-editor: org->gnome->desktop->privacy (uncheck remember-recent-files)
Why Failed? Doesn't work.

Method 5:
$ rm ~/.local/share/recently-used.xbel # clear current file history
$ touch ~/.local/share/recently-used.xbel # create a 0-byte history file
$ sudo chattr +i ~/.local/share/recently-used.xbel # make it readonly

[mrr]

Hi, just an idea.

Removing write attribute on a file doesn't prevent it to be modified
(that's a bit weird, no?).
Try (in a write permitted *directory*):
$ touch test1
$ chmod a-w test1
$ rm test1
rm: remove write-protected regular empty file ‘test1’? y

Well at least you do have a warning but the remove do work.
And:
$ mv test1 test2

Here, no warning at all, test1 is silently destroyed.

So what you could do (I guess you all know where I'm going and are
preparing yourself to answer "that's not a good idea"!) is:
$ > .local/share/recently-used.xbel
$ chmod u-w .local/share
$ rm .local/share/recently-used.xbel
rm: cannot remove ‘.local/share/recently-used.xbel’: Permission denied

I won't bother saying that this could have side effects especially when
installing a new application say vlc but I think that could work because
root can still create something in the share directory so the
.local/share/vlc would be created I guess, and as far as you don't touch
vlc permissions,it's ok; share permissions won't affect vlc.
And recently-used.xbel is the only regular file in my share folder.

I'm sure there might be more viable solutions, just take my comment for
what it is, just a note about file and folder write permissions and a
temporary solution (well I haven't tested but you don't run nautilus as
root, do you?)

Cheers,

--
mrr

[Bob Pack]

On Mon, 16 Feb 2015 08:42:19 +0100, mrr wrote:

> I'm sure there might be more viable solutions, just take my comment for
> what it is, just a note about file and folder write permissions and a
> temporary solution (well I haven't tested but you don't run nautilus as
> root, do you?)

What shocks me is that there is no known way to REMOVE that
Recent files entry.

Who uses it anyway?
I don't ever use it.

It wastes space. It's a privacy hole. And it's not even useful.
But, it's there. And, so far, it can't be removed.

I'll change the permissions again on the file, and let you know how
it works out.

[Godzilla]

I don't have nautilus, but for KDE, the only setting I can find are:

1.Right-click Application Launcher_Application Launcher Menu Settings_
View_untick Recently Used Documents.

2.Configure Desktop(System Settings)_Workspace Behavior_Activites Tab_
Privacy Tab_Remember opened Documents_tick Do Not Remember.

--
_____ _______ ____ __ __ _____ _
/ ____|__ __/ __ \| \/ | __ \ | |
| (___ | | | | | | \ / | |__) | | |
\___ \ | | | | | | |\/| | ___/ | |
____) | | | | |__| | | | | | |_|
|_____/ |_| \____/|_| |_|_| (_)

[mrr]

On 02/16/2015 08:15 AM, Bob Pack wrote:

> What shocks me is that there is no known way to REMOVE that
> Recent files entry.
>

Besides removing write permission in containing folder (as root, I
forgot to mention that in my previous message), 2 simple ideas:

- Write to nautilus developers.

- Have a cron job doing the work or an "in-session" and/or "out-session"
script.

- Modify yourself the source code (maybe it would be as simple to patch
it as in:
s/( .*)recently-used.xbel/\/dev\/null - and maybe not!!)

--
mrr

[Dirk T. Verbeek]

Op 16-02-15 om 13:41 schreef Godzilla:

> On 2015-02-16, Bob Pack <bp...@nospam.com> wrote:
>> On Mon, 16 Feb 2015 08:42:19 +0100, mrr wrote:
>>
>>> I'm sure there might be more viable solutions, just take my comment for
>>> what it is, just a note about file and folder write permissions and a
>>> temporary solution (well I haven't tested but you don't run nautilus as
>>> root, do you?)
>>
>> What shocks me is that there is no known way to REMOVE that
>> Recent files entry.
>>
>> Who uses it anyway?
>> I don't ever use it.
>>
>> It wastes space. It's a privacy hole. And it's not even useful.
>> But, it's there. And, so far, it can't be removed.
>>
>> I'll change the permissions again on the file, and let you know how
>> it works out.
>>
>
> I don't have nautilus, but for KDE, the only setting I can find are:
>
> 1.Right-click Application Launcher_Application Launcher Menu Settings_
> View_untick Recently Used Documents.
>
> 2.Configure Desktop(System Settings)_Workspace Behavior_Activites Tab_
> Privacy Tab_Remember opened Documents_tick Do Not Remember.
>

Indeed, as usual KDE has a configuration setting but it's not always
easy to find.

This thread is a good warning for those that mix&match KDE and Gnome/Unity.

[Dirk T. Verbeek]

Op 16-02-15 om 08:15 schreef Bob Pack:

> On Mon, 16 Feb 2015 08:42:19 +0100, mrr wrote:
>
>> I'm sure there might be more viable solutions, just take my comment for
>> what it is, just a note about file and folder write permissions and a
>> temporary solution (well I haven't tested but you don't run nautilus as
>> root, do you?)
>
> What shocks me is that there is no known way to REMOVE that
> Recent files entry.
>
> Who uses it anyway?

I do...

> I don't ever use it.
>
> It wastes space.

For you.

> It's a privacy hole.

No, that's who you share your password with.

> And it's not even useful.

For you.

[Robert Newson]

On 16/02/15 07:42, mrr wrote:
> On 02/16/2015 01:56 AM, Bob Pack wrote:
>> On Mon, 16 Feb 2015 00:50:33 +0100, Melzzzzz wrote:
>
>
>> Method 5:
>> $ rm ~/.local/share/recently-used.xbel # clear current file history
>> $ touch ~/.local/share/recently-used.xbel # create a 0-byte history file
>> $ sudo chattr +i ~/.local/share/recently-used.xbel # make it readonly
>>
>
> Hi, just an idea.
>
> Removing write attribute on a file doesn't prevent it to be modified
> (that's a bit weird, no?).
> Try (in a write permitted *directory*):
> $ touch test1
> $ chmod a-w test1
> $ rm test1
> rm: remove write-protected regular empty file ‘test1’? y
>
> Well at least you do have a warning but the remove do work.

That's because the rm has to modify the containing directory, not the
file itself: if you remove the write perm from the directory you will
not be able to rm any file, even if the file has read/write perms.

> And:
> $ mv test1 test2
>
> Here, no warning at all, test1 is silently destroyed.

No, test2 is silently destroyed (if it existed): again, what you've done
is modify the directory containing test1 and moved the link to the
actual data of the file from the directory entry named test1 to a
directory entry named test2.
...

> I'm sure there might be more viable solutions, just take my comment for
> what it is, just a note about file and folder write permissions and a
> temporary solution (well I haven't tested but you don't run nautilus as
> root, do you?)

The thing that was done with chattr (at the start of this message above)
is to set attributes of a file which are not permissions. One of the
attributes that can be set is called the Immutable (I) bit - if set no
changes whatsoever can be done to the file regardless of its permissions.

Try:
man chattr
and
man lsattr
for more information.

A trick that can sometimes work is to use a symbolic link to /dev/null
for the files that contains the information you don't want to keep
(ever) and want to prevent programs from filling, eg:

$ rm ~/.local/share/recently-used.xbel
$ ln -s /dev/null ~/.local/share/recently-used.xbel

after this ~/.local/share/recently-used.xbel points to a "black hole"
into which anything put disappears and out of which nothing can be got.

[Bob Pack]

On Mon, 16 Feb 2015 12:41:35 +0000, Godzilla wrote:

> 2.Configure Desktop(System Settings)_Workspace Behavior_Activites Tab_
> Privacy Tab_Remember opened Documents_tick Do Not Remember.

Thanks for that tip, as I just went to:
KDE > System Settings > Workspace Appearance and Behavior > Workspace Behavior
Activities > Privacy tab

That "Privacy" tab was set to "Remember opened documents" "For all applications",
and the "Keep history" was set to "forever" so, I set the privacy setting to
"Do not remember", and the "Keep history" button went away (as it should).

So, thanks for that suggestion. It didn't get rid of the "Recent" menu item
in Nautilus, but clicking on "Recent" has been showing nothing since yesterday,
so, I think changing the permissions on ~/.local/share/recently-used.xbel
seems to have worked (so far).

> 1.Right-click Application Launcher_Application Launcher Menu Settings_
> View_untick Recently Used Documents.

I right-clicked on the blue KDE application launcher in my panel, and
selected "Application Launcher Menu Settings" and in the "View" panel,
I had "Recently Used Applications" checked, which is ok, but I already
had "Recently Used Documents" unchecked, and "Recently Used" was also
unchecked.

I'm not at all sure *what* this affects, since it must have been set
that way for a long time, and yet, I still had the problem.

But I thank you for those two additional settings as it seems that
the privacy settings are all over the place, and nobody has them
listed together in one spot.

Thanks!

[DecadentLinuxUserNumeroUno]

On Mon, 16 Feb 2015 16:33:50 +0100, Dirk T. Verbeek wrote:

> This thread is a good warning for those that mix&match KDE and
> Gnome/Unity.

That is a pain.

I want lean XFCE type desk, but like gkrellm, and some KDE stuff too.

The "base library" of each should be expanded so using a single utility
does cause some cross compatibility crash.

The user then gets notified that installing said utility requires some
certain many tens of megabytes be added too.

Then there would need to be some running session management going on so
starting a gk applet under a KDE desktop session works seamlessly.

I do not see many problems, but I don't poke around like this a lot.

Ubu studio is XFCE. I see "crashes" I know are related to gnome tool
kit or kde, but never really hunted any of it down.

A base install doesn't do it, so it is all the stuff I add on that
creates the inconsistency.

[mrr]

On 02/16/2015 04:47 PM, Robert Newson wrote:
$ rm test1
>> rm: remove write-protected regular empty file ‘test1’? y
>>
>> Well at least you do have a warning but the remove do work.
> That's because the rm has to modify the containing directory, not the
> file itself: if you remove the write perm from the directory you will
> not be able to rm any file, even if the file has read/write perms.

Agreed, and ?
As far as I remember, it was exactly the point of my message.

>> And:
>> $ mv test1 test2
>>
>> Here, no warning at all, test1 is silently destroyed.
> No, test2 is silently destroyed (if it existed): again, what you've done
> is modify the directory containing test1 and moved the link to the
> actual data of the file from the directory entry named test1 to a
> directory entry named test2.
> ...

Agreed, test2 will have the same inode number actually. But that's not
the point here, on an application level (nautilus) it is the file name
that is relevant (after a quit/launch of nautilus to renew file descriptor).
If you were a developer you would know that a file is opened for example by:
int open(const char *pathname, int flags);
And afaik never using the inode number on user application level.
If you were doing kernel development, there you could (as far as file
system is an OS abstraction).

Still, a regular file (with a-w) can be modified by vim (with a warning,
ok) and you can see that the resulting file has a different inode.

>> I'm sure there might be more viable solutions, just take my comment for
>> what it is, just a note about file and folder write permissions and a
>> temporary solution (well I haven't tested but you don't run nautilus as
>> root, do you?)
> The thing that was done with chattr (at the start of this message above)
> is to set attributes of a file which are not permissions. One of the
> attributes that can be set is called the Immutable (I) bit - if set no
> changes whatsoever can be done to the file regardless of its permissions.
>
> Try:
> man chattr
> and
> man lsattr
> for more information.

Fair enough, you got me!
Some time ago the "i" attribute could be positioned but wasn't yet
implemented, I should have checked it!
That's why I spoke about chown and not chattr.
Anyway, that's good news.
I now feel sorry for my previous post, it's a lot of noise for actually
nothing! My bad guys.
And now I'm puzzled at how the recently-used.xbel file is being modified
by a regular user launched application.
Anyway you taught me something, thanks for that!

>
> A trick that can sometimes work is to use a symbolic link to /dev/null
> for the files that contains the information you don't want to keep
> (ever) and want to prevent programs from filling, eg:
>
> $ rm ~/.local/share/recently-used.xbel
> $ ln -s /dev/null ~/.local/share/recently-used.xbel
>
> after this ~/.local/share/recently-used.xbel points to a "black hole"
> into which anything put disappears and out of which nothing can be got.

Excellent idea, maybe not elegant but so simple and efficient (depends
on nautilus though I guess).
I should have thought about it :)
+1

--
mrr

[Bob Pack]

On Mon, 16 Feb 2015 22:53:38 +0100, mrr wrote:

> If you were a developer you would know that a file is opened for example by:
> int open(const char *pathname, int flags);
> And afaik never using the inode number on user application level.
> If you were doing kernel development, there you could (as far as file
> system is an OS abstraction).

I'm *not* a developer, so I'm confused as all hell why the "inode"
option worked to keep the file from being overwritten by KDE/Nautilus.

I had never seen that "i" before, in any "ls" listing, so, the
entire concept is new to me.

Here's what worked though, but which I don't really understand
with respect to the "i" in the middle of the long line of dashes:

Prevent the Nautilus "Recent" option from remembering files:
$ lsattr ~/.local/share/recently-used.xbel # check immutable attribute
-------------e-- /home/foo/.local/share/recently-used.xbel

$ rm ~/.local/share/recently-used.xbel # clear current file history
$ touch ~/.local/share/recently-used.xbel # create a 0-byte history file
$ sudo chattr +i ~/.local/share/recently-used.xbel # make it readonly

$ lsattr ~/.local/share/recently-used.xbel # check immutable attribute
----i--------e-- /home/foo/.local/share/recently-used.xbel

Somehow, this "i" in the middle of the dashes, prevents Nautilus
from remembering Recent files because it prevents Nautilus from
adding anything to the xbel file (whatever an xbel is).

[Bob Pack]

To give back to the team, there were *many* things suggested,
tried, and all failed (mostly due to the fact that they were
old solutions which no longer work or because they didn't work
with Nautilus on top of KDE on top of Kubuntu on top of Ubuntu).

Out of the many suggestions, here are the three things that did
do *something* to preserve recent-file related privacy though:

1. KDE > System Settings > Workspace Appearance and Behavior >

Workspace Behavior Activities > Privacy tab >

Change "Remember opened documents" "For all applications" and
"Keep History" "Forever" to:
"Do not remember", where the "Keep history" button goes away.

2. Right click on the blue "KDE" application launcher in the panel.
Select "Application Launcher Menu Settings" and then "View".
Uncheck "Recently Used Documents" and "Recently Used".

3. Prevent the Nautilus "Recent" from remembering files:

$ lsattr ~/.local/share/recently-used.xbel # check immutable attribute

-------------e-- /home/bob/.local/share/recently-used.xbel

$ rm ~/.local/share/recently-used.xbel # clear current file history
$ touch ~/.local/share/recently-used.xbel # create a 0-byte history file
$ sudo chattr +i ~/.local/share/recently-used.xbel # make it readonly
$ lsattr ~/.local/share/recently-used.xbel # check immutable attribute

----i--------e-- /home/bob/.local/share/recently-used.xbel

At the moment, nothing has successfully *removed* the recent entries;
all these workarounds simply make the value null (which is good enough
for government work).

[Robert Newson]

On 16/02/15 21:08, Bob Pack wrote:
> On Mon, 16 Feb 2015 22:53:38 +0100, mrr wrote:
>
>> If you were a developer you would know that a file is opened for example by:
>> int open(const char *pathname, int flags);
>> And afaik never using the inode number on user application level.
>> If you were doing kernel development, there you could (as far as file
>> system is an OS abstraction).
>
> I'm *not* a developer, so I'm confused as all hell why the "inode"
> option worked to keep the file from being overwritten by KDE/Nautilus

The inode number is not used to access files at the user level, but it
can be used at the user level to find different directory entries that
point to the same data eg:

$ touch file_1
$ ls -li file_[12]
364462 -rw-r--r-- 1 user group 0 20-02-16 21:49 file_1
$ ln file_1 file_2
$ cat file_2
$ cat > file_1
Hello world
^D
$ ls -l file_[12]
364462 -rw-r--r-- 2 user group 12 20-02-16 21:50 file_1
364462 -rw-r--r-- 2 user group 12 20-02-16 21:50 file_2
$ cat file_2
Hello world
$

file_1 and file_2 are exactly the same file (they both have the same
inode number - 364462)! They are two different filenames that point to
the same data (in this case in the same directory, but they could be in
different directories [that are in the same file system of a mount
point]). Further:

$ rm file_1
$ cat file_2
Hello world
$ cat file_1
cat: file_1: No such file or directory
$ ls -li file_[12]
364462 -rw-r--r-- 1 user group 12 20-02-16 21:50 file_2
$

The file into which the data was put (file_1) is removed (or more
accurately the directory entry which points to the data is removed), but
the data is still accessible by the entry file_2.

The way *nix [native] files systems work is to have a giant array of
pointers (nodes) which contain all the information (except one piece -
the actual filename) about the files (access permissions, dates of
access, size, etc). The index into this array is the index-node or
inode for short.

To access the data of a file, special files (called directories) are
used which contain a mapping between the filename and the inode. When
accessing the data the system traces through the directory structure to
find the filename which then gives it the inode of the data. This is
then copied into the kernel data tables when the file is opened - the
name is no longer used, and can even be deleted (unlinked/removed) from
the directory structure and still the data in the file will be
accessible (to the program which opened it).

> I had never seen that "i" before, in any "ls" listing, so, the
> entire concept is new to me.

It doesn't appear there as it isn't the normal *nix permissions. It is
accessible via the lsattr (list attributes) command instead.

> Here's what worked though, but which I don't really understand
> with respect to the "i" in the middle of the long line of dashes:
>
> Prevent the Nautilus "Recent" option from remembering files:
> $ lsattr ~/.local/share/recently-used.xbel # check immutable attribute
> -------------e-- /home/foo/.local/share/recently-used.xbel
> $ rm ~/.local/share/recently-used.xbel # clear current file history
> $ touch ~/.local/share/recently-used.xbel # create a 0-byte history file
> $ sudo chattr +i ~/.local/share/recently-used.xbel # make it readonly
> $ lsattr ~/.local/share/recently-used.xbel # check immutable attribute
> ----i--------e-- /home/foo/.local/share/recently-used.xbel

the 'i' in the middle of the dashes tells you that the i[mmutable]
attribute is set. With this attribute set, no change whatsoever can be
made to the file - it has become read-only and undeleteable to
*EVERYONE* including root.

For details see: man chattr

> Somehow, this "i" in the middle of the dashes, prevents Nautilus
> from remembering Recent files because it prevents Nautilus from
> adding anything to the xbel file (whatever an xbel is).

That's what immutable means: it CANNOT be changed by ANYTHING.

[Bob Pack]

On Mon, 16 Feb 2015 22:07:50 +0000, Robert Newson wrote:

> the 'i' in the middle of the dashes tells you that the i[mmutable]
> attribute is set. With this attribute set, no change whatsoever can be
> made to the file - it has become read-only and undeleteable to
> *EVERYONE* including root.

The "including root" part was a surprise!

Of course, I realize that root can use "chattr -i", so, it's not really
a limitation in active deletion; but it's nice to know that a passive
delete won't work under any circumstances.

[Bob Pack]

On Mon, 16 Feb 2015 22:07:50 +0000, Robert Newson wrote:

> The inode number is not used to access files at the user level, but it
> can be used at the user level to find different directory entries that
> point to the same data

Unfortunately, new errors are popping up in unexpected places when
I printed from gedit ...


(gedit:1418): Gtk-WARNING **: Attempting to store changes into
`/home/bob/.local/share/recently-used.xbel', but failed:
Failed to rename file '/home/bob/.local/share/recently-used.xbel.0VX9TX'
to '/home/bob/.local/share/recently-used.xbel': g_rename() failed:
Operation not permitted

(gedit:1418): Gtk-WARNING **: Attempting to set the permissions
of `/home/bob/.local/share/recently-used.xbel', but failed:
Operation not permitted

[Robert Newson]

That's the effect of the immutable bit - nothing can be done to change
the file in any way (until the bit is reset) - any attempt to change the
file in any way resulting in generating an error.

[Eef Hartman]

In alt.os.linux mrr <mir...@free.fr> wrote:
> Still, a regular file (with a-w) can be modified by vim (with a warning,
> ok) and you can see that the resulting file has a different inode.

It is not actually modying the file itself, it creates a NEW one
(that's why the different i-node) and then renames that file back to
the original filename (optionally retaining the old file as a backup).
So you see, vi doesn't need WRITE access to the original file as it is
not actually changing it, just renaming (as backup) cq removing it,
which only needs write access to the DIRECTORY it's in.

[Eef Hartman]

In alt.os.linux Robert Newson <noth...@bullet3.fsnet.oc.ku> wrote:
> pointers (nodes) which contain all the information (except one piece -
> the actual filename)

cq. filenames, and the pathname to the directories those filename(s)
are in.
The i-node does contain a "link count" though, which is the number OF
filenames that it's got (excepting symbolic links, those work in a
different way).

A directory is just a list of filenames and the i-nodes those names
point to. So it's a superlevel on top of the file structure itself
(the i-node table and the files, described BY those i-nodes).
Of course a directory is a file itself, so has an i-node too,
which makes it rather reecursive.

[mrr]

All that was quite interesting! I would just add that directory inodes
also contains 2 more entries that is itself and especially the parent
directory to allow relative addressing. The trick for "/" is that it
points toward itself. That allows things like in:
~ $ cd ../..///var

Coming back to the original question, if you want to get rid of the
errors, I would still suggest using a simple cron script to empty the
file at whatever speed is good for you.
You could do stuff more complicated too like modifying nautilus so as it
sends a signal to your process whenever it changes directory. Ok, as an
exercise maybe, I know that's like killing a bey with a rifle, let's say
I was thinking out loud!

Anyway, as previously mentioned, your privacy will be respected as far
as you don't share your desktop session.

Good evening European guys!

--
mrr

[Robert Newson]

On 17/02/15 09:29, Eef Hartman wrote:
> In alt.os.linux mrr <mir...@free.fr> wrote:
>> Still, a regular file (with a-w) can be modified by vim (with a warning,
>> ok) and you can see that the resulting file has a different inode.
>
> It is not actually modying the file itself, it creates a NEW one
> (that's why the different i-node) and then renames that file back to
> the original filename (optionally retaining the old file as a backup).

If that were true, if vim was used on a file with more than 1 link, the
backup would end up as the multi-linked file and the original file would
have a single link.

It doesn't - I have some files that are linked in two different
directories. If I use vim to edit one of them, the link in the other
directory still points to the edited file; try this:

$ touch file_1
$ ls -li file_[12]*
417840 -rw-r--r-- 1 user group 0 Feb 17 20:17 file_1
$ ln file_1 file_2
$ ls -li file_[12]*
417840 -rw-r--r-- 2 user group 0 Feb 17 20:17 file_1
417840 -rw-r--r-- 2 user group 0 Feb 17 20:17 file_2
$ vim file_1
{do the key stroks: ihello<ESC>ZZ
which inserts ``hello\n'' into the file}
$ ls -li file_[12]*
417840 -rw-r--r-- 2 user group 6 Feb 17 20:18 file_1
418250 -rw-r--r-- 1 user group 0 Feb 17 20:17 file_1~
417840 -rw-r--r-- 2 user group 6 Feb 17 20:18 file_2
$

As you can see, vim has not renamed file_1 as the backup as it keeps its
inode (417840) and the file_2 still points to the same data (as it
points to the same inode); a new inode (418250) has been used for the
backup file_1~

> So you see, vi doesn't need WRITE access to the original file as it is
> not actually changing it, just renaming (as backup) cq removing it,
> which only needs write access to the DIRECTORY it's in.

Wrong, vim *DOES* require the write perm on the file - see the above
little exercise/example!

[Bob Pack]

On Tue, 17 Feb 2015 19:37:52 +0100, mrr wrote:

> if you want to get rid of the
> errors, I would still suggest using a simple cron script to empty the
> file at whatever speed is good for you.

There do seem to be inherent advantages to emptying the file
at certain intervals (e.g., every two or three seconds, for example),
rather than making the file immutable (which causes other errors).

[Bob Pack]

On Tue, 17 Feb 2015 08:36:53 +0000, Robert Newson wrote:

> That's the effect of the immutable bit - nothing can be done to change
> the file in any way (until the bit is reset) - any attempt to change the
> file in any way resulting in generating an error.

I guess I can live with the error though I hadn't expected gedit
to cause a problem with this (now immutable) file, since it has
nothing, per se, to do with gedit in the first place.

[mrr]

On 02/17/2015 10:11 PM, Bob Pack wrote:
> I guess I can live with the error though I hadn't expected gedit
> to cause a problem with this (now immutable) file, since it has
> nothing, per se, to do with gedit in the first place.
>

It looks like gedit also use the same mechanism and file
(recently-used.xbel) as nautilus.
If you edit /file.txt I bet you would have an (xml) entry in the
recently-used.xbel file.
/file.txt would then become one of the "recent" opened file
In my recently-used.xbel I have all kinds of entries, ex: pdf, torrent,
and even epub knowing that I never read an ebook on my PC, I don't even
have some software to read it; I just copied some to my (standalone) reader.

Concerning the vim Robert had an excellent idea but I wouldn't say Eef
was completely wrong. I can't see that as a conditional situation but
until better explanation one could say:

- If number of hard link is 1 => new inode number so new file (by the
way, it's kind of weird if you edit a large file and save it often to
test it for example). I guess vim might be as low level as to reuse
actually written and not modified disk blocks.

- If number of hard links > 1 => keep the same inode (quite logic, apart
from searching the whole partition there is no simple way knowing who
else "own" the file so that it is the only way to modify the file and
keep consistency).

In both cases, no write permission => warning but you can go on if you want.

I'm puzzled!

(And happy the i attribute do works, that will be handy!)

--
mrr

[Eef Hartman]

In alt.os.linux Robert Newson <noth...@bullet3.fsnet.oc.ku> wrote:

> If that were true, if vim was used on a file with more than 1 link, the
> backup would end up as the multi-linked file and the original file would
> have a single link.

It seems to work differently - indeed - on files with multiple links,
probably just because it would break those links.

But a simple counterexample:
$ cat > 1
This is file #1
(press ctrl-d to end the input)
$ ll -i ?
1465 -rw-r--r-- 1 hartman beheer 15 2015-02-17 22:54 1
$ vi 1
(make a change)
$ ll -i ?
1656 -rw-r--r-- 1 hartman beheer 18 2015-02-17 22:55 1

You see that now the i-node DID change!

Done with VIM - Vi IMproved 7.2 (patched up to 416) on an older
Slackware system.

PS: when I add another link to 1 and then edit it it indeed does NOT
change the i-node:
$ ll -i ?
1656 -rw-r--r-- 2 hartman beheer 36 2015-02-17 23:08 1
1656 -rw-r--r-- 2 hartman beheer 36 2015-02-17 23:08 2

Note the link count in the 3rd field (normally 2nd, but with the -i
option an extra field for the i-node number is added in front).

[Bob Pack]

On Wed, 18 Feb 2015 00:00:04 +0100, mrr wrote:

> It looks like gedit also use the same mechanism and file
> (recently-used.xbel) as nautilus.

I guess, as long as it's just a warning, I'll just ignore it.
Thanks.

[Paul]

You can always redirect stderr :-)

2> /dev/null

I think I've used that, when a "find" command
starts returning "Permission denied" and fills
the screen with crap.

There won't always be an opportunity to slip one
of those in (like on a GUI launch), but you
could use that if running gedit from terminal

gedit --new-window somefile.txt 2>/dev/null

And then there should be less stuff left in the
terminal to ignore.

Paul

[Robert Newson]

On 17/02/15 22:13, Eef Hartman wrote:
> In alt.os.linux Robert Newson <noth...@bullet3.fsnet.oc.ku> wrote:
>> If that were true, if vim was used on a file with more than 1 link, the
>> backup would end up as the multi-linked file and the original file would
>> have a single link.
>
> It seems to work differently - indeed - on files with multiple links,
> probably just because it would break those links.

...
Well knock me down with a feather. Just checked and indeed if there is
only 1 link it does rename and write to a new i-node.

I suspect that this is because it is much faster (and system kinder) to
rename the file than to copy the contents to a backup file, which has to
be done with a multi-linked file.

[Richard Kettlewell]

Rename-into-place is usually done because it allows for atomic updates
to files.

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

[Jasen Betts]

a simple symlink (or possibly a hard link) to /dev/null might be sufficient.

/dev/null reads as empty and writes without error.

my nautilus doesn't list recent files so I can't test it here.



--
umop apisdn