Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER General Discussion Forum

Reply
 
Thread Tools Display Modes
Old 02-18-2020, 08:25 PM   #41
akademie
Human being with feelings
 
Join Date: Mar 2007
Posts: 3,978
Default

^^^ that exactly.
akademie is offline   Reply With Quote
Old 02-19-2020, 01:06 AM   #42
jrk
Human being with feelings
 
Join Date: Aug 2015
Posts: 2,969
Default

Quote:
Originally Posted by karbomusic View Post
I expect reaper should copy files correctly (when using Save As/Copy) and maintain the "Modified time" just like pretty much every copy operation in Windows.
Apologies. I got you wrong.

There's two things I don't understand.

(1) why should a copy file have the mtime of the original? I mean, it's a new file, it was last written to at the time the copy was made. Sure it has the same data as the original, but so what.

(obviously, there's cases like mirroring / restoring backups / archives where this is the behaviour we'd probably want)

2. Why have a workflow depend on the mtime? There's better ways
__________________
it's meant to sound like that...
jrk is offline   Reply With Quote
Old 02-19-2020, 01:36 AM   #43
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Quote:
Originally Posted by jrk View Post
Apologies. I got you wrong.

There's two things I don't understand.

(1) why should a copy file have the mtime of the original? I mean, it's a new file, it was last written to at the time the copy was made. Sure it has the same data as the original, but so what.

(obviously, there's cases like mirroring / restoring backups / archives where this is the behaviour we'd probably want)

2. Why have a workflow depend on the mtime? There's better ways
No worries...

For #1, a modification is about contents of the file - copy makes it even more justified so that one can know when the copy was made vs when the contents were last modified.

For #2, I explained the basic reasoning in my previous post. If the attrib is going to exist, it should accurately serve it's purpose - It's not about a workflow depending on it, it's about its value across the board. Even things such as sorting files is broken when the modified time is not retained properly. There are multiple times where it doesn't matter what the workflow is and the question inevitably comes up... "well when did the contents last change?" this field was designed to answer that question.

I don't have time to dig up the history but the reason that field exists should be for similar reasons; though I always thought all of this was kind of obvious.
__________________
Music is what feelings sound like.

Last edited by karbomusic; 02-19-2020 at 01:42 AM.
karbomusic is offline   Reply With Quote
Old 02-19-2020, 05:32 AM   #44
jrk
Human being with feelings
 
Join Date: Aug 2015
Posts: 2,969
Default

Quote:
Originally Posted by karbomusic View Post
No worries...

For #1, a modification is about contents of the file - copy makes it even more justified so that one can know when the copy was made vs when the contents were last modified.
Yep, that's the way it's often thought of. But is it? Under the hood it's the last time the file was written to (not *changed*). What if you change it, and then change it back to the way it was? How the heck should the file system know? And anyway, isn't this all down to copying files across devices? And also, who cares? There's better (IMHO) ways of doing project management than relying on mtime.
__________________
it's meant to sound like that...
jrk is offline   Reply With Quote
Old 02-19-2020, 08:18 AM   #45
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

It's not only thought of, it's the reason the field exists, it's not about or limited to copying across devices. Regardless of corner cases and scenarios you come up with, the field has a purpose and there needs to be a compelling reason for Reaper to not observe it - in all cases, it's a better idea to be consistent (good citizen) than willy nilly when given the choice.

At this point the devs should chime in as to why reaper doesn't preserve it, and if there is some reason reaper doesn't have the choice to do so. I may post this in bug reports as an "RFC" later.
__________________
Music is what feelings sound like.

Last edited by karbomusic; 02-19-2020 at 11:06 AM.
karbomusic is offline   Reply With Quote
Old 02-19-2020, 11:29 AM   #46
xpander
Human being with feelings
 
xpander's Avatar
 
Join Date: Jun 2007
Location: Terra incognita
Posts: 7,670
Default

Quote:
Originally Posted by akademie View Post
xpander did not make any proof, he opened the copied file afterwards and that way "edited" the copied file and then argues that modified date is not the same as original file that was copied
Correct, I certainly did not prove anything, I simply showed properties of couple of files and told what I saw there. Anybody can make their own conclusions from those. Me opening copied file afterwards is kind of a necessity to make edits to it, so I can show the attributes of the edited file. I don't understand your argument claim.

But here are new entertaining pictures. The difference here is that the original file has already been edited before being copied. If I'd have an argument to make with this one, that would be the obvious one of Modified attrib only carrying over to the first unedited copy. It would carry also to further unedited copies, but that is not shown here. The Created time of original is lost in copies, but that is a moot point, especially considering how files are created in Reaper. That I might have to go back and correct in my early replies. Thanks for the patience.


Last edited by xpander; 02-19-2020 at 02:01 PM.
xpander is offline   Reply With Quote
Old 02-19-2020, 11:32 AM   #47
jrk
Human being with feelings
 
Join Date: Aug 2015
Posts: 2,969
Default

Quote:
Originally Posted by karbomusic View Post
It's not only thought of, it's the reason the field exists,
You're confusing *purpose* with user-expectation. This user wouldn't necessarily expect this behavior.

As things stand, it's probably best to advise folks not to rely on mtime for their project management tasks, but rather use the other, better, features Reaper provides.
__________________
it's meant to sound like that...
jrk is offline   Reply With Quote
Old 02-19-2020, 12:15 PM   #48
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Quote:
Originally Posted by jrk View Post
You're confusing *purpose* with user-expectation. This user wouldn't necessarily expect this behavior.

As things stand, it's probably best to advise folks not to rely on mtime for their project management tasks, but rather use the other, better, features Reaper provides.
Purpose = expectation here and you are going in circles a number of times now.

You are also being argumentative while bringing exactly zero value to the thread, please let the "argument ad nauseum" go because it's not helping anyone in any way unless you can provide something of actual substance which you have yet to succeed at.

If you can't do better with your argument, you should probably pack it in - there's nothing useful in your replies for any of us to reply to at this point and is mostly noise.

If I have time, I'll just debug this myself and raise the question to devs in bug reports.
__________________
Music is what feelings sound like.

Last edited by karbomusic; 02-19-2020 at 12:22 PM.
karbomusic is offline   Reply With Quote
Old 02-19-2020, 01:19 PM   #49
jrk
Human being with feelings
 
Join Date: Aug 2015
Posts: 2,969
Default

Well, that's nice. To go back to the OP.

"Why is this a big deal? Well there are times when I have items no longer in the project, but they are in the project folder. I may want to know why they are no longer being used and if they have anything of value, so I sort by date."

Srsly. If it doesn't work. Don't do it. You've established that it doesn't work the way some folks expect, but you persist in calling this the problem. It's not a problem. Folks insisting on using a non-feature and being annoyed when it doesn't work is the problem.

Using Reapers project management tools (clean project / consolidate / whatever) isn't a workaround. Eyeballing mtimes is a workaround - what? Perfectly good features. Does it work? Not always. Hence pointless.

If this issue had come across my desk in the old days I'd have said "we should document this". "Cool" everyone would have said, "Docs bug, next!";

All the best.
__________________
it's meant to sound like that...
jrk is offline   Reply With Quote
Old 03-16-2020, 10:28 AM   #50
bezee
Human being with feelings
 
Join Date: Jan 2020
Posts: 4
Default

Quote:
Originally Posted by jrk View Post
I get that, but you're (kinda) wrong. There's better ways to accomplish what your example is about.

Also, Reaper (or any application) depends on the filesystem to manage these timestamps. Which is not to say that the application couldn't use utimes() or the equivalent or whatever to fake the times to your liking - but there's no advantage to it that I can see.

If you can come up with a use case that isn't provided for in some other way, then you've got a legitimate gripe. Not just "I wanna achieve this (fair enough) but in some way that doesn't, in fact, work (questionable)".

Perhaps I've misunderstood.
So what are you telling me here..? That the modification date is useless for sorting my project files?

Let's make a scenario: You are in charge of mixing an album for a band and are given boxes of tapes for each instrument. Unfortunately for YOU, each box has multiple tape reels that are undated. One band member says the drum take on February 22 was the best, while the drummer says his best take was on March 16. Now the guitarist disagrees and says the first take was the best. Wait... when was the first take done? Now it's up to you to sort through every tape one by one and find the best take. Shame they weren't dated, otherwise you could quickly narrow things down.

1. Organization is key with any project, but especially big ones. File names themselves do not cut it for sorting takes. Sorting by date is huge.

2. REAPER is changing the modified date to the current date when the file is copied to the project. This should not be happening!

3. Windows, Linux, and Mac ALL PRESERVE MODIFICATION DATES WHEN COPYING FILES. A copy is not a modification according to file systems!
bezee is offline   Reply With Quote
Old 03-17-2020, 03:11 PM   #51
akademie
Human being with feelings
 
Join Date: Mar 2007
Posts: 3,978
Default

Hurray
The Modified time issue when simple copying is fixed in v6.05+dev0316

Quote:
Originally Posted by xpander View Post
v6.05+dev0316 - March 16 2020
...
+ File copying: when making byte-for-byte copy of media, preserve file modification time [t=231551]
...
Thank you boys
akademie is offline   Reply With Quote
Old 03-17-2020, 04:13 PM   #52
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Excellent! Thanks for letting us know.
__________________
Music is what feelings sound like.
karbomusic is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 06:35 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.