nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nano-devel] questions about uniquely numbered backups


From: Benno Schulenberg
Subject: [Nano-devel] questions about uniquely numbered backups
Date: Tue, 28 Apr 2015 13:44:56 +0200

Hi all,

When nano is used with the options --backup and --backupdir set,
it will make a uniquely named and numbered backup of the file
currently being edited whenever this file is saved.  It will
store this backup file in the specified directory.

For example, when running 'nano --backup --backupdir=~/STORE NEWS'
in the directory ~/Repositories/NANO, and then typing ^O <Enter>,
nano will store the file '!home!ben!Repositories!NANO!NEWS~' in
/home/ben/STORE.  Upon a second save it will store
'!home!ben!Repositories!NANO!NEWS~.1'.  And then .2, and then
.3, and so on.

Now, when this number reaches the ten thousands, things start
to slow down, because for every save, nano iterates through all
the earlier numbers, checking whether the file already exists.
All these stats take time.  On my system, simulating the existence
of a million earlier backup files, it takes nano some ten seconds
(it varies from 9 to 12) to find the next free filename.  And nano
will happily go to four billion backup files (on my system, where
ULONG_MAX is 4294967295), at which point it would take some
*twelve hours* to find a free file name and save the file.
Totally absurd.

So I think nano should report much earlier than that that there are
too many backup files -- I would say before the delay comes close
to a second.  On my system that would mean some 100,000 backup
files.  If you make twenty backups (of the same file) per day,
you can edit continuously for nearly fourteen years before
hitting that limit.

Currently, when nano does hit the limit, it will display this message:
[ Error writing backup file 
/home/ben/STORE/!home!ben!Repositories!ANYTHING!NEWS: Too many backup files? ]

On an 80-column terminal it would look like this:
[ Error writing backup file /home/ben/STORE/!home!ben!Repositories!ANYTHING!NE ]

It gets truncated, and the important part of the message gets lost.
So I suggest leaving out the actual filename and also condensing the
wording a bit, so that it is more likely to fit:
[ Cannot write backup file to /home/ben/STORE/: Too many of them? ]

Any objections?  And... is there anyone who actually uses this
numbered-backups feature?

Benno

-- 
http://www.fastmail.com - Send your email first class




reply via email to

[Prev in Thread] Current Thread [Next in Thread]