China DOS Union

Because when backing up, in order to prevent changes to the files after backup, all files after backup have been set to "system + read-only" attributes. If the original attributes of these files are not restored when restoring the files, some unexpected problems will occur: for example, operations such as renaming and updating the content of the restored files can no longer be performed. This is also a problem I discovered when restoring the files, so the operation of attributes is added.

Of course, when backing up, the /k parameter can be used to maintain the original attributes, but after doing this, changes to the files after backup cannot be prevented. For the safety of backing up files, it is better to make it more complicated :)

When replying to other posts, I checked the code for date detection in this script again. I found that if we want to detect the input of week - style dates, the principle is actually the same as that of digital - style date detection. It just needs to use a certain trick in the findstr command. So I immediately stayed up late to improve the date detection.

There are still issues with the function of restoring files from backup files, mainly regarding the file naming problem. Please do not use this function for the time being. If you want to use it, manually modify the file name in the generated *_revert.bat file to avoid restoration errors.

Who is willing to come and improve this script? Mainly the part of restoring the backup.

I can only support you spiritually. We still need to work hard

The part of operating the backed-up files has been improved. Generally speaking, the basic functions of this script for backup purposes have been available. The remaining work mainly is to find bugs and streamline the code. I hope everyone is not intimidated by the large amount of code and all come to test it.

Re: namejm:

To be honest, I still don't agree with adding too many attribute operation codes to the program for the sake of protecting backup files. Because compared with the high cost of code and performance we put in, the probability that backups with various attributes are artificially modified and damaged won't be reduced much. This is also the main reason why I can't consider updating and testing the restore module.

Maybe only adding attributes to the target directory is a compromise. The effect is similar to the method of adding attributes to all targets, but the cost is much lower.

Of course, if you insist on the original view, then I put forward an improvement suggestion for the for statement in the get_attrib segment of attribute operation:

for %%a in (a s h r) do echo %%i|findstr "%%a">nul && set a%%a=+%%a || set a%%a=

echo attrib !aa!!ah!!ar!!as!%%j >>"%batch_directory%\%name%_revert.bat"

[ Last edited by willsort on 2006-7-29 at 23:46 ]

Re:

　　The reason why I initially added the "System + Read-only" attribute to each target file was to make the system automatically prompt whether the user really wants to perform operations like deletion or renaming when they accidentally do so for one of the files. It wasn't intended to deal with deliberate destruction. If I really wanted to deal with deliberate destruction, I could use the method of md test.. to create a folder that can't be accessed or deleted by conventional methods to store backup files. However, I gave up this malicious idea considering that there might be a need to access the backed-up files : )

　　If I only add attributes to the top-level target folder, the risk prevention ability is slightly weaker than the current plan, but the efficiency of setting up backup tasks is improved. There are both advantages and disadvantages. This version still keeps the current plan. Replace my original part with the simplified code you provided and see everyone's opinions first. Thanks for your continuous attention and code provision.

[ Last edited by namejm on 2006-8-1 at 01:17 ]

Re namejm:

Found one obvious and one less obvious error in the code at building 67. The code at building 67 and the top floor has been corrected.

There is a missing echo before attrib in the second sentence, and a space should be added after %%j; otherwise, it will error when %%j is a single digit.

Hehe, willsort is really meticulous, even noticing such a细微 place. Under your prompt, I also discovered that this code should have added a line setlocal enabledelayedexpansion before, to avoid delay errors.

Tested the current code and found two relatively serious problems, both related to the parameter /s in the line xcopy /d /h /i /g /q /s /x /y "%source%" "%destination%":
1. When a file (not a folder) is in the root directory, sometimes the copy fails and prompts "Cannot perform periodic copy";
2. If there are files with the same name in the directory under the file to be copied, all the same-named files will be copied;

The key to solving problem 1 is to distinguish whether to copy a file or a folder when using xcopy;
And the solution to problem 2 is a bit tricky: if the parameter /s is removed, only the first-level files of the specified folder can be copied, and the subfolders under the folder cannot be copied; if the parameter /s is not removed, this problem cannot be avoided.

[ Last edited by namejm on 2006-7-30 at 23:07 ]

May I ask the moderator if he can post the modified entire program for everyone to share?

Moderators, can you release the entire modified program so that everyone can enjoy it?

It took some time to solve the two problems on floor 70; when testing again, I found that in the line "for %%a in (a s h r) " by moderator willsort on floor 67, the "a" attribute seems a bit redundant because in testing it was found that any file has the "a" attribute, so there's no need to consider adding it with attrib again. This can save a lot of attribute operation code in the batch processing after restoring the backup; by the way, I also found and modified several errors.

Re chainliq:

From now on, both bat and exe format files will be provided for download at the top of the thread, with simple instructions. Thanks for your attention.

[ Last edited by namejm on 2006-8-1 at 01:38 ]

Looking forward to everyone's testing. If you have any questions, please post a reply. It needs everyone's joint participation.

To be honest, I haven't read this whole post yet. Oh, I need to go back and read it to learn.