PDA

View Full Version : Backup and Proccess_ID



Scott Lambert
April 21st, 2012, 05:04 PM
I am thinking about a fourth option for config(F_Backup_Mode).

Vedit is capable of getting the Windows process id for the current instance of vedit thru the Process_id string variable or pid for short.

One of the options for config(F_backup_mode) is to put the original file in user_home\backup.

I was thinking for the fourth option, vedit could put the original in user_home\backup but append the pid to the filename.

In testing, I find that you are very unlikely to get the same pid, so the upshot would be that you would have also every version of a file in your backup folder, instead of just the previous.

The reason it needs to be a new options, is first if you like the .bak option, having a buch of bak files would be annoying. Second if you edit multi-GB size files, this could also be annoying.

Just an idea....

Scott

chriz
April 22nd, 2012, 12:36 PM
Another idea:

What about an additional "custom" option for config(F_Backup_Mode)?

In that case a special macro (or text register) would be called with the filename in question as parameter and the user is able to code any special backup handling by himself.

Christian

pal
April 23rd, 2012, 04:40 AM
I don't like the idea of using PID, it is just a random number.
Why not just use an incrementing number. It would be like a version number of the file.
This could be a separate option, "Multiple backup versions" or something like that, and it could be used when the backups are stored in the original folder, too.

By the way, VMS operating system used such a versioning system. Each time you changed a file, a new file was created with versioin number incrementing, e.g. main.c#1, main.c#2, main.c#3...
If you asked for file main.c, VMS would automatically open the latest version, but you could choose any other version by giving the version number in the file name.
VMS did automatically delete older versions after a time (I am not sure if it was limited by time or by the number of versions), but you could delete them manually, too.

There is another advantage with incrementing version number. It would solve the overwriting problem.
If you have multiple files with the same name in different directories, they currently overwrite each other in the backup directory.
Using PID would not solve this problem if you edit those files during the same session.

folioite
April 23rd, 2012, 06:25 AM
How about just inserting the date/time stamp into each backup's filename, run the time out to one or two decimals and problem solved.

If I am wanting to go to a previous version, I am most likely to know that I want to go back to last Friday afternoon, since that is when I suspect that I messed up the file (for one possible situation)...

chriz
April 23rd, 2012, 06:49 AM
I don't like the idea of using PID, it is just a random number.
Why not just use an incrementing number. It would be like a version number of the file.
This could be a separate option, "Multiple backup versions" or something like that, and it could be used when the backups are stored in the original folder, too.

I coded something like that for Vedit years ago.
It's not automatic but needs to be called when needed. I've it in the {User} menu for easy access.

// - Save current file as new version (name generated automatically)
// - Load old version of the currently loaded file
// - Delete old versions of the file
// - Compare current file with an old version
// - Customize the behavior via dialog

If anyone is interested: http://www.ziemski.net/vedit/macros/filevers.vdm


Christian

Scott Lambert
April 23rd, 2012, 10:39 AM
Another idea:

What about an additional "custom" option for config(F_Backup_Mode)?

In that case a special macro (or text register) would be called with the filename in question as parameter and the user is able to code any special backup handling by himself.

Christian

Actually we already have the special register, the file pre-open event macro register, which could be used for this purpose.

Or perhaps easier from a programming angle, just have custom file save & file save as macros to replace what is in the menu.


Scott

Scott Lambert
April 23rd, 2012, 01:14 PM
[QUOTE=pal;304]I don't like the idea of using PID, it is just a random number.

Since one can sort the backup folder by date, it is simple to get the file version you need. It is easier to remember, it is Tues version you want then #13.

Second with the using the pid, one could develop a macro that could reload all files having the same pid, sort of a secondary session restore feature. Just a thought, not sure if there would be any call for that.

Scott

mrvedit
April 23rd, 2012, 04:59 PM
I like the option of creating a backup with the date.
The PID could just be another option. Trivial to implement both options.
Ted.

pal
April 25th, 2012, 11:08 AM
The problem with using date/time stamp is that when you close Vedit, all the files are closed at the same time.
Thus, any files with the same name may be overwritten.

folioite: You do not need to include the date in the filename, since you can see the date in the dir listing.

By the way, one way to get unlimited backups is to use revision control system, such as RCS.
I made RCS support for Vedit many years ago, but I have not been using it for a long time.
I used file-pre-open and file-post-close event macros for automatic check-out and check-in.

folioite
April 25th, 2012, 11:58 AM
Pal,

You make a good point. here are my thoughts:

When you close Vedit, the only files that might close at the same time are those that have already been saved, so, no NEW backup file will generated.
Any files that have not been saved are prompted for confirmation whether you want to save them or not. Even if you choose "Save-All" the timestamp for each one will be different, even if only by a fraction of a second, thus, if the backup file's filename is appended with the last-saved date/time, and that time is run out to a hundredth of a second, they will all always have different timestamps.


IF you have two files of same name open at the same time, they will of necessity have to be residing in different directories, so, their backup files, even if they have an identical timestamp in their filename, will not get overwritten as each backup will go in the folder with the original file.
A Vedit user (who is typically smarter than the average bear) is opening files of same name in different directories, he would know automatically to not have backup files all put in the same folder, if that is even possible.


The other reason (and main reason, to me) for having the date/timestamp appended to the filename of the backup is to validate the integrity of that backup file.
If its real date/time varies from the one appended to its filename, then, that can alert the user to the fact that that backup file may have been modified since it was generated.

pal
April 26th, 2012, 04:32 PM
folioite:

The whole idea was to save the backups in backup directory. And an important improvement was to be able to use backup directory even if files have the same name.

If you close Vedit and you are prompted for saving files, you have option All, which saves all files without prompting. So they will be saved practically at the same time.
Modern computers are fast. Saving a file on hard disk may take less than 1/100 seconds. When saving on flash disk, it is matter of microseconds.

However, Vedit does not even have 1/100 seconds resolution. I think the most accurate time stamp available on Vedit is time_tic. It gives time in milliseconds, but my tests show that the actual resolution is 15 or 16 milliseconds.
I made a small test program:


#1 = Time_Tick
File_Save(NOMSG)
#2 = Time_Tick
Num_Ins(#1)
Num_Ins(#2)
After making some change so that the file needs to be re-saved, I ran the macro.
In almost every run, #1 and #2 had the same value. Thus, if it had been saving backup files, the two files would have the same filename.

But of course, in most cases the filename would be different. That would be improvement to current situation, since now the filename is always the same when saving in the backup directory.


However, the filename with timestamp would be quite ugly, for example main.c.2012042417250120

folioite
April 30th, 2012, 07:18 AM
Pal,

You have me smiling :)

I agree that timestamp in the filename is "ugly" (been doing it for years).
But, if "ugly" discouraged me, I would remove all mirrors from my view!!!!!

I would suggest that Ted place some separators in that date/time stamp to make it more readable: for example main.c.2012-0424_17:25:01.20

Of course, this might be one of several options, so, we can all choose the least-ugly solution for each of us....

I wonder if Windows would allow two files in the same folder with identical names? I would think if this occurred, the attempt to name that second file identically would be halted by Windows and the appropriate dialog would pop up, and the user would then tell Windows what to do.... This should solve the dilemma of them being saved too fast.

ian binnie
April 30th, 2012, 08:01 PM
Pal,
I would suggest that Ted place some separators in that date/time stamp to make it more readable: for example main.c.2012-0424_17:25:01.20

Of course, this might be one of several options, so, we can all choose the least-ugly solution for each of us....

PLEASE if implemented DO NOT invent another format - use ISO8601



I wonder if Windows would allow two files in the same folder with identical names? I would think if this occurred, the attempt to name that second file identically would be halted by Windows and the appropriate dialog would pop up, and the user would then tell Windows what to do.... This should solve the dilemma of them being saved too fast.

Well not identical, but you can have names which differ only in case.
NTFS is case sensitive, so the files are different, but as far as Windows is concerned they are the same.

folioite
May 1st, 2012, 07:09 AM
ISO8601 is fine. But, we are only talking about backup files, so, ISO or no ISO, as long as it is easily readable, it should work :)

apityshtolzea6029
April 20th, 2018, 06:47 PM
Best quality real passports provider: w w w. buyrealpassport.cc