XYplorer Beta Club

First a question...

Is there an anomaly concerning copying and pasting files? When I copy a file and then paste it, the "Created" time stamp of the copied file is updated to "now", but the "Modified" time stamp is preserved from the original file. Is this what should happen? It doesn't seem right to me

Now my wishes...

I would like to see the copy and paste function update the "Created", "Modified" and "Accessed" time stamps on the copied file to "now".

I would like to see a new Paste Special option that will set the copied file (or files) "Created", "Modified" and "Accessed" time stamps to whatever the original file (or files) were.

I would also like to see this option was also available on the context menu when right dragging files.

What do others think?

Cheers
JohnM

JohnM wrote:When I copy a file and then paste it, the "Created" time stamp of the copied file is updated to "now", but the "Modified" time stamp is preserved from the original file. Is this what should happen? It doesn't seem right to me

I would like to see the copy and paste function update the "Created", "Modified" and "Accessed" time stamps on the copied file to "now".

Retaining the Modified date is how Win Expl does it, and that's how I expect it to work, as thus the relationship to the original is maintained...I can then use the Modified date to help sync the folders of the original and copy, which would be harder to do if dates differed.

I'd suggest that, as alternative, any special date settings be controlled by a combination of toggle options and "paste special"...as that behavior could thus be customized to user preferences.

I'm with JC on this one.

The idea of it being in the "Paste Special" is a nice one, perhaps even with an option to make it "default" in the ini?

Paste Special sounds like a good compromise to me.

Cheers
JohnM

Ok bumping this just to say that, I agree that the current behavior is the "normal"/expected one and shouldn't be changed ; however I think adding a feature in the Extended D&D menu of XY (right D&D) so after being moved/copied files would have their timestamps (Modified) changed to "now" would be a good idea!

jacky wrote:Ok bumping this just to say that, I agree that the current behavior is the "normal"/expected one and shouldn't be changed ; however I think adding a feature in the Extended D&D menu of XY (right D&D) so after being moved/copied files would have their timestamps (Modified) changed to "now" would be a good idea!

And for what purpose?

Not to answer your question Don, but isn't this kinda like an "Auto-Touch" feature? I believe it's referred to as touching a file when you modify the dates without changing the actual file no?

Hmm, just did a very quick Google and came up with this: http://www.opengroup.org/onlinepubs/007 ... touch.html

Seems it's a UNIX type thingy. This basically what you're asking for though right Jacky?

My point, if I have one, is that if this kind of capability is added to XY it would make sense (to me, cos I'm like that) to add it completely, rather than just the "now" option.

And what would be nice is if XY were to keep the folder date when moving it from one place to another.

John

admin wrote:And for what purpose?

Well for example, I have someone here that uses a soft that will work on all files in a folder (and its subfolders) to do some work, etc. And to identify which files must be included in the work, the Modified date is used & remembered each time.
This works well, but only when this guy is the only one who works on those files. Problem is, since others (well, me ) happen at times to work on those aswell, when I'm done & send them back if in the mean time a process has been launched, then the files I've modified will not be treated, though they should.

Now if either while I copy them or he does their Modified dates could be changed, this problem would disappear.

jacky wrote:And to identify which files must be included in the work, the Modified date is used & remembered each time.

Hmm. Maybe that method is a bit weird? And I shall support this?

admin wrote:

jacky wrote:And to identify which files must be included in the work, the Modified date is used & remembered each time.

Hmm. Maybe that method is a bit weird? And I shall support this?

Don't think it's really weird no... I mean how else should files that have been recently worked on/modified be found, so all operations aren't done each time on all files but only those which have been modified? That's pretty much why the Modified date is here, isn't it?

jacky wrote:Don't think it's really weird no... I mean how else should files that have been recently worked on/modified be found, so all operations aren't done each time on all files but only those which have been modified? That's pretty much why the Modified date is here, isn't it?

But apparently the way you're "working" on these files doesn't set the modified date when you safe it, that's maybe the weird part of the situation.

RalphM wrote:But apparently the way you're "working" on these files doesn't set the modified date when you safe it, that's maybe the weird part of the situation.

No it does, but what I'd need is to have the Modified dates for those files set to "now" when they're copied, as in once the work is done they all get their Modified date to that date, even files that were only last modified on the begining of the work 3 days ago...

I cannot set the modified date in the target files. I could only set it before copying in the source files. But the wish is so exotic that I'd rather let you do it by hand. Find information about XY's time-stamping in the wiki.

What might be a nice idea here would be a one-click command "Set all selected items' modified date to now". Hm?

Hi.

John Bee wrote:And what would be nice is if XY were to keep the folder date when moving it from one place to another.

I'd also like to have such a feature, I like to keep my folders' creation timestamps when copying or moving them to a different partition, and currently I have to pack them with WinRAR and extract them at the desired destination in order to accomplish that, which is far from an ideal solution.

Any chance of having this feature in a future version of XYplorer?