Menu
▾
▴
#56 all: Bug with clone of dates when copy directory tree.
There is "forever" standing bug in all DOpus Amiga versions, that was corrected in DOpus 6 (PC version) and following. When one copies all the contents of a directory tree, file dates are cloned, but directory dates are the current creation dates.
Several years ago I wrote an ARexx routine that runs just after the copy is ended and clones all the original directory dates, so for me the problem is solved. Anyway, fixing it in DOpus "copy" code is the right way.
That's not a Dopus bug, it's an AmigaDOS feature. Whenever a file is added, removed or changed in a directory, the directory date is set to the date of the latest change. If you change any files in a directory that have had the dates set by your ARexx script, the directory date will be changed by AmigaDOS anyway.
Last edit: xenic 2015-10-13
The note kindly reported here by kas1e was taken from MorphZone, where I posted about the subject. Unfortunately I was too much concise and my words can be interpreted erroneously, so let me explain the problem in detail just to remove any possibility of bad interpretation.
I reported that when one uses DOpus 5 to copy a directory, say "DH0:TEST" to "DH1:", the directory "DH1:TEST" created in the process is not a perfect clone if it contains some subdirectories. Byte contents are correctly copied, the problem affects the dates. File dates are cloned, i.e. "DH1:TEST/report.txt" has exactly the same datestamp as the original file "DH0:TEST/report.txt"; "DH1:TEST/SUBDIR/anotherfile.txt" has exactly the same datestamp as the original file "DH0:TEST/SUBDIR/anotherfile.txt", and so on. On the other hand, all copied subdirectories acquire the current date and time and lose the original date and time, i.e. "DH1:TEST/SUBDIR" is dated "today 12:35:44" while the original date of "DH0:TEST/SUBDIR" was, for instance, "25-Jul-13 23:54:03".
All subdirectories created in "DH1:TEST" just acquire the current datestamp instead of the original date of creation they have in "DH0:TEST". This is true at every nested level; even DH1:TEST" itself is affected.
This erroneous behaviour was corrected on PC's in DOpus 6 and all the following versions, which in the example above would create "DH1:TEST/SUBDIR" setting its datestamp to "25-Jul-13 23:54:03".
I corrected this behaviour 15 years ago by means of an AREXX routine that scans all the subdirectories in "DH0:TEST", reads their datestamps, and then sets the datestamps of all the corresponding subdirectories in "DH1:TEST" to the correct values. This routine is automatically launched after any copy command executed by DOpus 5.
In my original report I suggested that the correct behaviour (set by DOpus 6 and following versions) should be implemented directly in the copy command of DOpus 5.
Last edit: DoctorMorbius_FP 2015-10-14
This is no bug, it's a feture of the OS.
However, an option to keep dates during clone/copy whould be nice.
Well, I refer to MorphOS, and since in a CLI window I can use the OS command:
Copy <directoryname> TO <destination> CLONE
and it keeps all directory dates, I presume it is at least a feature of MorphOS.</destination></directoryname>
Anyway let me say that this "bug or feature" dilemma is a rather philosphical question: the most important thing is that both of us (and others, I hope) agree that adding such an option would be nice.
Ambient and C:Copy command (that originates from AROS) call SetFileDate() when they have finished copying a directory.
In DOpus() this probably would go to Program/function_copy.c, maybe somewhere along lines 996.
I ran some tests and that seems to be a good place to change dates for sub-directories but not the right place to change the date of top top-level directory. My tests show that changing the directory dates complicates another Dopus5 feature:
If you copy a source lister directory to a destination lister that contains a directory with the same name; the files and subdirectories are copied into the destination directory. For example: Copying "hd1:somedir" to "ram:somedir" will add the contents of "hd1:somedir" into "ram:somedir" and the directory dates for the destination "somedir" will be updated. Copying the directory and sub-directory dates could result in destination directory and sub-directory dates being set to the older dates from the source directory. That doesn't seem logical to me and some users might object to copying directory dates in that case.
Added copying of directory dates when Environment/Copy settings have 'DateStamp' selected. Dopus5 can now copy directory dates in addition to file dates. If there are no bugs or complaints for this change within a week or 2 this item will be closed.
I'm sorry for the delay of this reply, but just after my previous post my wife had (and unfortunately still has) severe health problems, so I had no time to check what happened here...
You made an optimal choice by making selectable the cloning of directory datestamps (the same is true in the PC version). I made some tests in my MorphOS environment and this new feature works perfectly here (as you already know, I presume).
Let me thank you very much for your work, xenic!