I've just moved a lot of sub-folders of a main folder into another main folder (same hard disc).
The modified timestamp of all sub-folders have been changed to "now".
When I copy the sub-folders - the modified timestamp does NOT change (in Preferences / File Operations / copy Attributes / Preserve the timestamp of copied files is selected).
Why does the modified timestamp of a "moved" folder change? The content of the sub-folder(s) itself did not change!
Is it possible to avoid this? Are there any settings in DO? It completely changes the "view" when something has been done in the sub-folder.
The modified timestamp of both (source, destination) main folders have changed (as awaited - because they changed).
Moved a folder from my local C: to another local C: folder. Modified timestamp does not change on destination. OK
Moved a folder from my C: to USB-stick. Modified timestamp does not change on destination. OK
In the example above I moved inside a network drive (M:) (in the company) and the modified timestamp changes. NOT OK
I think this is the reason why the modified timestamp changes! But it does not when I copy & delete (aka move) it. Maybe due the setting "Preserve modified timestamps of copied files" in DO (= DO put the hands on it).
DO should also put the hands on it when I "move" it.
It's possible something is reacting to the change and modifying something below the moved folders as a result, in turn causing their timestamps to be bumped.
When I move or copy on my local PC (C: or my connected USB) - the modified timestamp does not change.
When I copy on the company network drive M: - a DFS (Distributed File System) (copy a folder from M: to M: !) - the modified timestamp does NOT change.
But when I move from M: to M: the modified timestamp CHANGES.
Why?
Let's say: A COPY + DELETE should be prefered over a MOVE to avoid a change of the modified timestamp ?
I saw the latest DO 10.2 changes on video and made the same very useful coloring of "show all files + folders in color (yellow) if modified in the past one hour" ... and those "moved" folders are now all yellow.
[quote="fuzi1968"]When I move or copy on my local PC (C: or my connected USB) - the modified timestamp does not change.
When I copy on the company network drive M: - a DFS (Distributed File System) (copy a folder from M: to M: !) - the modified timestamp does NOT change.
But when I move from M: to M: the modified timestamp CHANGES.
And when I copy or move between 2 different DFS systems (L: => M:) the modified timestamp also does not change.[/quote]
Moves between devices are done as a Copy-then-Delete, and Opus will (if configured) copy the timestamps across afterwards.
Moves on the same device are done as a simple Rename, and the tempstamps should not need to be modified.
What about when you move on the same local partition?
And what happens if you move a folder on the same DFS using Windows Explorer? Or just rename it from a Command Prompt?
Maybe the problem is that your DFS server/filesystem is changing the timestamp on moved/renamed folders.
Where in the video (minutes & seconds) are you referring to?
After renaming back I tried the move on the Command Prompt:
M:\SECA>dir
Volume in drive M is DATA
Volume Serial Number is FC29-8782
Directory of M:\SECA
2012-10-17 10:09 <DIR> .
2012-10-15 08:45 <DIR> ..
2012-10-17 10:03 <DIR> UML
2012-10-17 10:03 <DIR> Misc
2012-10-17 08:52 <DIR> Brokerjet
0 File(s) 0 bytes
5 Dir(s) 1.209.774.084.096 bytes free
M:\SECA>move Misc UML
M:\SECA>dir UML
Volume in drive M is DATA
Volume Serial Number is FC29-8782
Directory of M:\SECA\UML
2012-10-17 10:10 <DIR> .
2012-10-17 10:10 <DIR> ..
2010-05-10 21:10 532.914 UML2.2-Visio2003.zip
2010-05-10 21:09 933.156 SOPHIST UML2 V1.6.zip
2012-10-17 10:10 <DIR> Misc
2 File(s) 1.466.070 bytes
3 Dir(s) 1.209.770.602.496 bytes free
Only the "move" on the same DFS CHANGES the modified timestamp.
The rename (and copy) on the same DFS does NOT change the modified timestamp.
[quote]Where in the video (minutes & seconds) are you referring to?[/quote] Hmm ... early at the beginning after showing the new different DO versions (light/pro). .. However - not important.
From the logical point, a "move" is a "copy + delete" - regardless if it is on the same drive or not.
The tricky thing here is that Windows/DO uses "rename" when "moving" on the same drive letter because the result under Windows - which is "sitting" on these kind of drives (FAT32, NTFS) - is the same result.
Copy from C: => C:
C:\Test>dir
Volume in drive C is Festplatte
Volume Serial Number is 7044-29C0
Directory of C:\Test
2012-10-17 12:08 <DIR> .
2012-10-17 12:08 <DIR> ..
2012-10-17 12:08 <DIR> TestDir
0 File(s) 0 bytes
3 Dir(s) 124.268.838.912 bytes free
C:\Test>dir ..\Test2
Volume in drive C is Festplatte
Volume Serial Number is 7044-29C0
Directory of C:\Test2
2012-10-17 12:08 <DIR> .
2012-10-17 12:08 <DIR> ..
0 File(s) 0 bytes
2 Dir(s) 124.268.838.912 bytes free
C:\Test>copy TestDir ..\Test2\TestDir
TestDir\Testfile.pdf
1 file(s) copied.
C:\Test>dir ..\Test2
Volume in drive C is Festplatte
Volume Serial Number is 7044-29C0
Directory of C:\Test2
2012-10-17 12:13 <DIR> .
2012-10-17 12:13 <DIR> ..
2012-10-17 12:13 1.069 TestDir
1 File(s) 1.069 bytes
2 Dir(s) 124.268.834.816 bytes free
=> Normal copy => new timestamp.
=> Will be avoided with the DO preference "Preserve the timestamps of copied files".
Move from C: => C:
C:\Test>del ..\Test2\TestDir
C:\Test>dir ..\Test2
Volume in drive C is Festplatte
Volume Serial Number is 7044-29C0
Directory of C:\Test2
2012-10-17 12:18 <DIR> .
2012-10-17 12:18 <DIR> ..
0 File(s) 0 bytes
2 Dir(s) 124.269.506.560 bytes free
C:\Test>move TestDir ..\Test2\TestDir
1 file(s) moved.
C:\Test>dir ..\Test2
Volume in drive C is Festplatte
Volume Serial Number is 7044-29C0
Directory of C:\Test2
2012-10-17 12:19 <DIR> .
2012-10-17 12:19 <DIR> ..
2012-10-17 12:08 <DIR> TestDir
0 File(s) 0 bytes
3 Dir(s) 124.269.506.560 bytes free
=> Windows/DO only runs a "rename" for the "move" on the same drive. From the logical point it would have to update the timestamp. I see it more or less as a bug.
=> If Windows/DO would emulate the "move" correctly, a "copy" + "delete" would change the timestamp. And as a follow up DO would preserve the timestamp and all would be fine also.
Rename on C:
C:\Test>move ..\Test2\TestDir .
C:\Test>dir
Volume in drive C is Festplatte
Volume Serial Number is 7044-29C0
Directory of C:\Test
2012-10-17 12:26 <DIR> .
2012-10-17 12:26 <DIR> ..
2012-10-17 12:08 <DIR> TestDir
0 File(s) 0 bytes
3 Dir(s) 124.269.211.648 bytes free
C:\Test>rename TestDir TestDir2
C:\Test>dir
Volume in drive C is Festplatte
Volume Serial Number is 7044-29C0
Directory of C:\Test
2012-10-17 12:27 <DIR> .
2012-10-17 12:27 <DIR> ..
2012-10-17 12:08 <DIR> TestDir2
0 File(s) 0 bytes
3 Dir(s) 124.269.211.648 bytes free
a) It only happens when you move (via rename) a folder from one location on the DFS to another on the same DFS.
b) It happens whether you use Opus, Windows Explorer or a Command Prompt.
c) It does not happen when you do the same operation on something other than the DFS.
The DFS is bumping the timestamp of directories when they are moved (via rename). End of story.
It has nothing to do with Copy vs Rename, either. When you copy a directory, you create a brand new directory, which will (of course) have the current timestamp. Opus (if configured to) expects that and will then copy the timestamp over to the new directory afterwards.
Copying the timestamp should not be needed after a rename (and is not needed on anything but that DFS) so Opus doesn't do it.
The DFS is at fault, or at least not behaving the same as a normal drive. This has nothing to do with Opus and everything to do with the DFS.
C:\Test>dir
Volume in drive C is Festplatte
Volume Serial Number is 7044-29C0
Directory of C:\Test
2012-10-17 12:27 <DIR> .
2012-10-17 12:27 <DIR> ..
2012-10-17 12:08 <DIR> TestDir2
0 File(s) 0 bytes
3 Dir(s) 124.269.088.768 bytes free
C:\Test>dir M:\SECA\Test2
Volume in drive M is DATA
Volume Serial Number is FC29-8782
Directory of M:\SECA\Test2
2012-10-17 13:07 <DIR> .
2012-10-17 12:34 <DIR> ..
0 File(s) 0 bytes
2 Dir(s) 1.207.691.968.512 bytes free
C:\Test>copy TestDir2 M:\SECA\Test2\TestDir2
TestDir2\Testfile.pdf
1 file(s) copied.
C:\Test>dir M:\SECA\Test2
Volume in drive M is DATA
Volume Serial Number is FC29-8782
Directory of M:\SECA\Test2
2012-10-17 13:08 <DIR> .
2012-10-17 12:34 <DIR> ..
2012-10-17 13:08 1.069 TestDir2
1 File(s) 1.069 bytes
2 Dir(s) 1.207.691.513.856 bytes free
=> Same as C: => C: and M: => M:
=> Normal copy => new timestamp.
=> Will be avoided with the DO preference "Preserve the timestamps of copied files".
Move from C: => M:
C:\Test>del M:\SECA\Test2\TestDir2
C:\Test>dir M:\SECA\Test2
Volume in drive M is DATA
Volume Serial Number is FC29-8782
Directory of M:\SECA\Test2
2012-10-17 13:10 <DIR> .
2012-10-17 12:34 <DIR> ..
0 File(s) 0 bytes
2 Dir(s) 1.207.690.919.936 bytes free
C:\Test>move TestDir2 M:\SECA\Test2\TestDir2
Access is denied.
0 file(s) moved.
=> DOS command "move" does not work like in Explorer or DO.
To avoid this problem - to change the timestamp on a "move" - DO must support it because DO uses the tricky Windows "rename" which has the "side effect" not changing the timestamp on a "move".
So it would be great if DO supports e.g. the following options in the preferences:
"Preserve the timestamps on file systems like DFS".
Sub-Option of "Preserve the timestamps of copied files" and only selectable if the parent option is selected.
If selected, DO should also preserve the timestamp after a "move" (not "rename" but could!) on a DFS itself.
See my reply above, and please ignore anything to do with Copy, and anything to do with Moving between devices (Copy-then-Delete), as both are irrelevant and just confusing the matter.
The important thing is what happens when a folder is Moved on the same device (i.e. Move via Rename). Your DFS is bumping the timestamp when that happens, and it shouldn't be.
I just see the whole comment with examples from M: => M: is missing in this thread. And you didn't wait for my next comment.
Is it possible to support a "move" and preserving the timestamp (rename works in this case) on a DFS itself? Maybe in the "Advanced" section. I think I'm not allone.
Just reading in a magazine that Windows 8 will suport "Storage Spaces" where you can connect multiple phyiscal storage devices to one logical device (like a DFS).
I don't have Windows 8 yet but how does copy/move/rename work with "logical devices" regarding the timestamps?
