中国DOS联盟

Re willsort:

　　Adding the code provided by the moderator at the very beginning of this program script, if not "%1"=="$" %comspec% /f:on /c %0 $ && goto :eof, indeed enables the function of automatically completing the file name. However, during testing, the strange phenomenon shown in the following figure was discovered.

　　The condition for the problem to occur is: when entering a file name that is much shorter than the previous one by pressing Ctrl+F or Ctrl+D, there will be remnants of the previous file name after the current file name. If it is shorter each time, more remnants will appear, but it does not affect the correct execution of the program.

　　In addition, I don't understand the exact meaning of this code. Can the moderator explain it?

Re namejm:

This phenomenon also occurred in my test, and it also exists in the CMD environment. This is also one of the "additional effects" I mentioned. Currently, I haven't found a good solution, and I can only speculate that there are some problems with the cmd auto-completion feature. However, it doesn't occur every time the file name changes from long to short. I hope other experts can think about the specific pattern and solutions, or you can post a help topic in the command line area or the Q&A room.

Regarding the meaning of the if not sentence, it means that when the first parameter of the command line is not "$", use cmd (where %comspec% points to the location of cmd) to re-invoke the batch script itself, and add the first parameter $ at the same time to prevent repeated invocation of cmd. Because we need to use cmd /f:on to enable the extended features of auto-completion, and using cmd in the batch script will create a new cmd environment, thereby interrupting the running of the batch script, so we need to use /c %0 afterwards to re-enter the batch script itself.

This is the so-called "batch script re-entry" technology. Here, the re-entry technology is used to obtain a new command line environment that meets specific requirements to interpret a special batch script or itself ; while at other times, the re-entry of the batch script is not through cmd but through call or directly invoking the batch script, which is usually to achieve the re-setting of command line parameters .

In addition, the known additional effects also include: all environment variables in the batch script will become "local" and will become invalid after exiting the batch script; the system environment variable %cmdcmdline% will be modified; a new cmd instance (process) will be added in memory during operation.

A Brief Analysis of the Helpless Signature Code
http://www.cn-dos.net/forum/viewthread.php?tid=18838

Some Technical Discussions about HDKP
http://www.cn-dos.net/forum/viewthread.php?tid=12892#pid95281

Closed: Change the file names to 001.txt 010.txt...100.txt
http://www.cn-dos.net/forum/viewthread.php?tid=14512

Last edited by willsort on 2006-6-7 at 21:32 ]

Re: namejm:

Just now, after a simple test, it can be determined that the auto-completion only has problems when re-completing files or directories with Chinese names (or other multi-byte character names). The discussion thread has been forwarded to the command line area .

But it is estimated that this problem cannot be solved in the short term, and considering that it does not affect normal use, you can consider not dealing with it for the time being. Of course, you need to make your own balance between using it or not. In addition, set /p is similar to the command prompt of cmd. You can use a series of features of DOSKey to scroll through the history commands with the cursor keys. Of course, these commands include the file names that were previously entered. You can also use function keys such as ESC, F1 to F10 to assist in input. In addition, you can also use the copy and paste function in the right-click menu.

In addition to this, I am still thinking about whether this program can be changed from timed backup to regular backup to avoid the problem of often missing the backup time. Of course, this requires a large-scale modification of the code, and you need to make a balance.


The auto-completion feature of CMD has problems with Chinese file and directory names
http://www.cn-dos.net/forum/viewthread.php?tid=21091

Re considerations:

　　After thinking about it later, the filename auto-completion function is a relatively advanced technique. If the forum moderator hadn't brought it up, I估计 many people wouldn't have thought of it. And in this script program, there is already a way to select files by dragging, which is very convenient, and there are no unexpected issues when running; however, using the filename auto-completion function requires using combination keys to select multiple times to find the file to back up, which is relatively cumbersome, and moreover, it will bring some troubles. Based on the above situation, I think the filename auto-completion function can probably be removed. Personal opinion, welcome to discuss.
　　On my computer (xp+sp2), I have been using the function of using the arrow keys of doskey to scroll through historical commands. I don't know if it's enabled by default in the system, so I didn't make this aspect of the prompt in my script program. The paste method was not prompted, and it will be improved in the next version to facilitate operation; and the function keys like ESC, F1~F10 were not prompted, which is because I feel that there might not be such cumbersome input when entering, so there is no need to make any prompts.
　　I don't know the specific operation of the forum moderator's regular backup. Isn't scheduled backup already containing the function of regular backup? Please make it clear to the forum moderator.
　　Recently, I've been busy with unit matters, and I will have more time to consider the update of this script after 6.10. Please forgive everyone.

Re: namejm:

The algorithm difference between regular backup and scheduled backup mainly lies in that it will no longer rely on "scheduled tasks", or mainly no longer rely on "scheduled tasks".

The regular backup algorithm is mainly described as follows:

First, hook its own code or corresponding task code with the automatic running mechanism at system startup to ensure that it can run every time the system starts; then, when running, judge whether the current date meets the conditions preset by the user. If it matches, start the specified task; otherwise, do nothing.

The core of the algorithm lies in the automatic running hook and date condition judgment. I only have relatively preliminary ideas in these two aspects, and there are still some details to be perfected.

The advantage of the algorithm is that because it can adopt the task validity period mechanism, it can greatly avoid the possibility that "scheduled tasks" are skipped because the system is not started, which is more beneficial to individual users who cannot keep the computer running uninterruptedly.

Originally posted by willsort at 2006-6-9 02:30:
Re namejm:

The advantage of the algorithm is that because it can adopt the task validity period mechanism, it can greatly avoid the possibility that "scheduled tasks" are skipped due to the system not starting, which is more beneficial to individual users who cannot keep the computer running uninterruptedly.

　
　　I have added code to force the startup of scheduled tasks in the script, which should ensure that the scheduled tasks can be used. I don't know if it is effective in relatively BT settings, and everyone needs to do more testing.

　　Even if the scheduled task startup fails, but the code to start automatically when booting has been added, the backup script can still run every time the computer boots, which can make up for the lack of scheduled task startup failure to a certain extent.

　　At present, this is considered a double insurance approach. The boss may have a more perfect solution. Can you reveal it?

Re namejm:

For example, set backup task A to run every 7 days starting from the 1st. But if the user never boots the system on the 1st, the task obviously can't be executed; then, suppose the user boots the system on the 2nd, does the task A need to be executed at this time? As for a backup task, generally it is needed; then, the user boots the system again on the 3rd, does the task A need to be executed again at this time? Usually it is not needed.

This is just the usual situation, and we may also need to take care of users' more complex needs. For example, the user can set that if the task is overdue for 1-2 days, it will be executed automatically; if it is overdue for 3-4 days, it will ask whether to execute; if it is overdue for 5-6 days, it will not be executed; and after the overdue task is executed, is the next task execution time readjusted according to the new cycle or does it keep the original timing cycle?

These are difficult to achieve with scheduled tasks. In addition, scheduled tasks have more defects, such as being unable to set the task to run when the system boots, being unable to set the task to run when the total running time of the system reaches a certain limit, and even being unable to set the task to be executed every 4 days or every 5 days (not fixed days of each month). So, I personally never use "scheduled tasks".

In short, timing sets the "clock", and periodicity sets the "deadline". As for which one is more in line with the designer's positioning and the user's needs, that is another more complex issue.

For the requirement of running once every N days or once every time the computer starts, you can use the schtasks command in XP and later systems to achieve it.

After reading the introduction of this command, I feel it is very powerful, but behind the powerful functions is the drawback of too many optional parameters. If this command is used in an interactive interface, it will definitely make users keep making choices, and too much interference will increase the user's workload. And I want to make this script minimize the user's operations, so I will definitely give up some functions.

Of course, DOS is not omnipotent, and I don't expect this script to replace the backup programs written in various high-level languages at present. It's just learning while using, seeing how much repetitive work batch processing can save for me and what conveniences it can bring, etc. Trying to extract as much as possible the efforts of batch processing is what I am eagerly seeking :P

BTW, I believe there are other functions that can be developed for this script, but I haven't thought of them yet, and I'm still learning. Thank the moderator for the guidance all the time, and I hope you can continue to pay attention. Thanks.

Re namejm:

Briefly flipping through schtasks, it should be the full-function command-line interface for scheduled tasks under XP, which is indeed a lot more enhanced than at. Thanks for the brother's tip!

As for the problem of too many parameters, because for backup tasks, many parameters can take default values, and the number of really selected items is not many, so it can be simply encapsulated with code.

If there is anything that can be enhanced, it is the backup mode and command-line interface.

The current backup mode adopted by the program is differential backup. Of course, there are some other backup modes, such as synchronous backup, incremental backup, etc. These modes should also be achievable with batch processing.

As for the command-line interface, it is mainly to simplify the design of task scripts. If more backup modes are added, writing the backup code into the task script is too cumbersome. And if the code is written into the host script, and only the calling interface is written in the task script, the task script will be much simpler; then we can consider directly writing the backup task in the form of a command line into the command line of the scheduled task, thus omitting the design of the task script.

Last edited by willsort on 2006-6-10 at 18:48 ]

Re:

　　"Then you can consider directly writing the backup task in the form of a command line into the command line of the scheduled task, thus omitting the design of the task script."
　　——I think if I do this, it will deviate from the original intention of my designing this script: allowing users to complete the backup without remembering the command format, just by following the prompts for simple input operations.

　　In addition, I don't know the specific concepts of incremental backup and synchronous backup; also, what does "host script" mean? I'm a newbie, the kind who gets confused when seeing more professional terms; don't laugh at me :o

Re: namejm:

For the backup mode, please refer to .

The command-line interface is for backup tasks, not for users themselves. That is to say, the backup tasks created by users according to the wizard originally include a scheduled task and a corresponding task script, and this script is relatively independent of the file backup tool. Now, we can make this task script directly call the corresponding backup module in the file backup tool. At this time, because the task script is generated by the file backup tool and its functions are also supported by the file backup tool, I call the current file backup tool the "host script".

An extremely simplified task script will have only one command line, and tasks such as detection, judgment, backup, and logging are all handled by the host script, and this command line can be written into the key values of the scheduled task or Run. At this time, the task script will no longer exist.

For backups for restoration
http://www2.ccw.com.cn/05/0528/b/0528b16_1.asp

After reading the article "Backup for Restoration", I think differential backup is better. Because my positioning for this script is: it just needs to meet the needs of personal users to back up important small files, and basically does not consider backing up files of hundreds of megabytes. As for more complex backup modes, if anyone is interested, they can develop it by themselves, and it doesn't have to use CMD commands.

Regarding the idea of "host script", I think it is still a bit complicated and difficult to implement: if the task script is to call the relevant modules in the file backup device, then the location and file name of the file backup device must be fixed; if the task script is canceled and the command is written into the at command line or the registry run, then how to assign values to the variables in the relevant modules in the backup device to know which file is to be backed up and where it will be backed up to?

Added error detection for date and time input, but it's not perfect yet. Please let experienced people correct it.

Thanks to bagpipe for providing the code.

An added a relatively practical function: restoring files from the backed-up files to the original directory.

This function actually cost me almost a whole day. The difficulty was in recording the attributes of each file, folder, and their corresponding ones, and then operating with the attrib command. At the beginning, I required myself not to generate temporary files, but it was in vain. I had to relax the requirement, reducing the temporary files from 3 to 1, and finally made this module.

When making this module, I gained some insights: for example, when traversing the directory with for /r, the attribute of hidden files cannot be detected by %~ai, but after using dir /a /s /d in the parentheses after in, it can be perfectly solved.

Still hope to not generate temporary files, and hope that experts will pay attention.

Re namejm:

Currently, the necessity of attribute operations has not been observed. xcopy can choose to copy attributes, and the switch is /K. There are also related switches /R and /H.