‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’’
@PeterJones
Let me get this straight: you want to modify (change) the file, then save it, but not have the file’s modification time changed?
Yeah.
… to follow standard practices
Whose standard practices and for whom?
The essence of the question is exactly to move away from standard practice.
… otherwise, the modification time becomes meaningless.
Hm-m… Meaningless… For you? May be.
But for me - just vice-versa.
… you want to corrupt the modification time, …
Do not say such things out loud.
I want to keep it unchanged. You see the difference between this terms?
… on your own, after saving, you can use …
Thank you. Very much!
I have a lot of I can and before, and after :)
I have the bundle of such applications for Windows.
And surrogate automation I have already now.
However, I want not ‘after saving’, but instead of it, by the forces of Npp itself.
‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’’
@gstavi
Obviously … API …
I think so too.
However, nothing prevents to save opened file’s attributes in dark and cool place, and then bring them back. There are a lot of SetFileTime related functions.
… that is typically reserved for malicious users.
And you too - do not say such things out loud.
‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’’ @Scott Sumner
The OP did not state WHY s/he wanted to retain the file’s old modification time. Let’s presume there is a perfectly valid reason for wanting this.
Thank you for moral support :)
… would cause N++'s File Status Auto-Detection …
May be. And Monitoring too.
But it is a very special case and the interference of these functions should simply not be allowed at the level of the Npp itself. Especially because the timestamp changing event will raise twice - first by OS, and the second - by Npp, when time stam will restored.
I have ownwrited application that run 24x5 and I use API Function ‘WriteFile’, constantly appending data w/o closing handle. I tried now on this remoted PC to open this log in old Npp 6.6.2 - Auto-Detection do not work. I try open it as share on my desktop Npp 7.3.2 - nor Auto-Detection, nor Monitoring not work. But the file is intensilty appending :) and OS show the unchanged time of file creating.
‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’‘’’
OK. At least - few words about wtf it need for me :)
I often have to go to the archives of code, both my own and others. In Far-manager this is all quite easy and meticulously (time, content, size) is compared. Troubles appears when the difference between files is in extra space, linebreak etc. It need to correct 2-3 bytes of code, but, getting identical content, I loose historical timestamp, in first, and in second - got error of compare by time :)
It is very troublesome to use a third party programs for this purpose - it nee to save original time by some manner, edit-save file and set saved time, that need to be passed by some manner too…
If Npp had this feature, but I already guess that it does not have it, then it would be enough to spit out the file from the archive, edit it and throw it back.
.