moderated After file move, upload date is incorrect #bug


 

When you move a folder, the upload date is incorrectly changed to the date it was moved.

I just lost hundreds of dates on cat folders, all of which were changed to read as this morning and last night, when I did the reorg. Those dates were information that was going to be helpful in deciding which ones to remove based on age. It's true that when you click on the moved folder, you can then see the dates of the individual files within it. But now, unlike before the move, it's impossible to see the actual date of the folder until you go inside of each individual one.

Can this be fixed, and fixed retroactively?
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


 

Hi J,

On Thu, Feb 10, 2022 at 8:49 AM J_Catlady <j.olivia.catlady@...> wrote:
When you move a folder, the upload date is incorrectly changed to the date it was moved.

I've made the following changes:

- The `Uploaded` column has been renamed `Updated`.
- There's a new column `Created` which shows the creation/upload date of the file/folder.
- I've made the Files display horizontally scroll if there isn't enough space, like on a phone.

Please let me know if you have any questions.

Cheers,
Mark


 

Mark,
Fantastic. Thanks. I'll check it out right now.
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


 

Mark,

I don't like the term "updated" if the folder/file was just moved, because it implies there's been some change to the contents on that date, whereas there hasn't. What I'm looking for in a file or folder date - of any kind - is whether or not the file is active in some way, so that, for example, I can delete it if not. I think the term "updated" for having simply moved something is misleading. 

Here's an example that shows how misleading the terminology can be: suppose I create a folder for inactive files or folders, content that's over a certain number of years old without any recent (by whatever definition I decide on) changes or updates. When I load something into that folder, it immediately gets a notation that it has been "updated" on that date. And that seems completely wrong.

Is it possible not to make any change in any date for a file or a folder that was simply moved?
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


Andy
 

Mark,

I am thrilled to see this deficiency finally fixed.  It has bothered me for years that the displayed dates were wrong.  I procrastinated about sending a bug report.  Bad me.

But why even have the "Updated" column?  Who needs it?  If the only thing that happened was moving or renaming a file, then the file itself is unchanged and its only date should be the upload or creation date.

From my point of view (recognizing that not everyone may agree), a file's date should be the date it was either uploaded, or edited and saved.  No other date matters.  Rename the file?  It's the same file.  Move the file?  It's the same file.  Edit the file?  Now it gets a new date.  Change the description?  In my opinion it's the same file so the original date is what matters and should remain unchanged.  Editing a file online or changing its description are the only reasons I can think of for a different "Updated" date; and even then, I don't really care to have a second date, but I suppose someone else might.

Also, did you fix the massive screw-up that happened on February 7, 2020?

Andy


 

On Thu, Feb 10, 2022 at 02:11 PM, Andy wrote:
Editing a file online or changing its description are the only reasons I can think of for a different "Updated" date; and even then, I don't really care to have a second date, but I suppose someone else might.
I couldn't agree more. If I move from SF to NY, have I been "updated" or am I the same person? :-)
 
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


Andy Wedge
 

On Thu, Feb 10, 2022 at 10:11 PM, Andy wrote:
did you fix the massive screw-up that happened on February 7, 2020?
I'm not sure that can be recovered based upon the response to  my previous query on that.

Regards
Andy


billsf9c
 

> afile's date should be the date it was either uploaded, or edited and saved.  No other date matters. 

Since, "it depends," ideally we might have 2-4 check boxes to show which date(s) we wish to maintain. But it becomes a bit onerous a thing to ask for. We might, on rate occasion, want change tracking as a good wiki has. That might get worked into some future Pro list.

I'd settle for a check box to keep an original date OR date updated.

An easy way would be to be "stuck" with a default date unless we manually enter a date, overriding the default.

I generally add a date at the start of any file or include it in the Name or Description. Dates are important, but which date can indeed, vary. This is hard to accommodate.

BillSF9c


 

I think there needs to be both an “updated” date, reflecting actual change to the file itself (description or new file etc), as well as an original date (which could be called  “created” or “uploaded”). 

The problem with the current change is that a file that simply moves to a new address is now marked as “updated” and assigned the date of the move as the date of the alleged, but nonexistent, update. 

It’s not so much a matter of how many dates to maintain . It’s a matter of currently misleading information, and loss of the true date of the file’s actual latest update).


On Feb 11, 2022, at 10:27 AM, billsf9c via groups.io <OOWONBS@...> wrote:

> afile's date should be the date it was either uploaded, or edited and saved.  No other date matters. 

Since, "it depends," ideally we might have 2-4 check boxes to show which date(s) we wish to maintain. But it becomes a bit onerous a thing to ask for. We might, on rate occasion, want change tracking as a good wiki has. That might get worked into some future Pro list.

I'd settle for a check box to keep an original date OR date updated.

An easy way would be to be "stuck" with a default date unless we manually enter a date, overriding the default.

I generally add a date at the start of any file or include it in the Name or Description. Dates are important, but which date can indeed, vary. This is hard to accommodate.

BillSF9c

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


 

Hi All,

I've changed the behavior of the Updated field. A file/folder's Updated field is now only changed for the following actions:

- A new version of the file is uploaded
- If it's a link, if the URL is changed
- If the description of the file/folder has changed

No other actions modify the Updated field (ie. moving/renaming). Please let me know if you have any questions.

Thanks,
Mark



 

Hi Mark,

The several hundred folders I moved still have their "updated" date set to the day I moved them a couple of days ago. So it seems the change is only for *future* file moves? Is there any way to get the old, actual "updated" dates back?
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


 

On Fri, Feb 11, 2022 at 1:45 PM J_Catlady <j.olivia.catlady@...> wrote:

The several hundred folders I moved still have their "updated" date set to the day I moved them a couple of days ago. So it seems the change is only for *future* file moves? Is there any way to get the old, actual "updated" dates back?

Correct, the changes only affect future actions. For activity previous to this change, those database fields were overwritten and I have no way to get back the previous values.

Mark 


 

Ok. Thanks. 


On Feb 11, 2022, at 2:23 PM, Mark Fletcher <markf@corp.groups.io> wrote:


On Fri, Feb 11, 2022 at 1:45 PM J_Catlady <j.olivia.catlady@...> wrote:

The several hundred folders I moved still have their "updated" date set to the day I moved them a couple of days ago. So it seems the change is only for *future* file moves? Is there any way to get the old, actual "updated" dates back?

Correct, the changes only affect future actions. For activity previous to this change, those database fields were overwritten and I have no way to get back the previous values.

Mark 

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


Andy
 

I am adding this as a reply to the existing thread because it's related, even if it might be a distinct question.

Now that we have separate "Created" and "Updated" dates for Files, it bothers me how they work.  Maybe it's just me, but I want to think that the "Created" date corresponds to the date the file was uploaded to the group.  Whereas "Updated" includes incidental changes to how the file is listed here, such as moving it, or changing its filename, or changing its file description - none of which alter the file itself.

But, if someone uploads a new copy of a file, replacing the original one with a brand new file, the "Created" date remains the same!  That's not right, in my opinion.

Technically, the file with that filename (well, a file with that filename) was created earlier, and altered today by replacing it with a brand new file.  You might argue that it was only "updated" today.  But I beg to differ.  The file that is there now, did not exist until today.  The file that was uploaded last week is gone.  The listing should - in my opinion - say that the file was "created" today, not last week.  I want to know that the file that's there now was uploaded today, making it for all practical purposes a new file.

Regards,
Andy


 

Moving a file no longer counts as an update. That was the whole reason for my OP.  

I think that changing the description is correctly categorized as an update, as does replacing the file. Replacing it is the very definition of an “update”. If you want a new “created” date, you would delete the file and upload a separate one. 


On Feb 19, 2022, at 8:14 AM, Andy <AI.egrps+io@...> wrote:

I am adding this as a reply to the existing thread because it's related, even if it might be a distinct question.

Now that we have separate "Created" and "Updated" dates for Files, it bothers me how they work.  Maybe it's just me, but I want to think that the "Created" date corresponds to the date the file was uploaded to the group.  Whereas "Updated" includes incidental changes to how the file is listed here, such as moving it, or changing its filename, or changing its file description - none of which alter the file itself.

But, if someone uploads a new copy of a file, replacing the original one with a brand new file, the "Created" date remains the same!  That's not right, in my opinion.

Technically, the file with that filename (well, a file with that filename) was created earlier, and altered today by replacing it with a brand new file.  You might argue that it was only "updated" today.  But I beg to differ.  The file that is there now, did not exist until today.  The file that was uploaded last week is gone.  The listing should - in my opinion - say that the file was "created" today, not last week.  I want to know that the file that's there now was uploaded today, making it for all practical purposes a new file.

Regards,
Andy

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


Andy
 

On Sat, Feb 19, 2022 at 12:38 PM, J_Catlady wrote:
Moving a file no longer counts as an update. That was the whole reason for my OP.  
 
I think that changing the description is correctly categorized as an update, as does replacing the file. Replacing it is the very definition of an “update”. If you want a new “created” date, you would delete the file and upload a separate one. 

In the end, uploading a new version of an existing file is no different from deleting the old one and uploading a new one.  But there are two ways to get there.  One is to manually delete the old file and upload the new file.  The other is just uploading the new file, which replaces the old one with the new one, by internally deleting the old one and uploading the new one, done in one step from the user's point of view.

Why should it matter whether it is done in one step or two steps?  Both accomplish the same thing, which is that the old file is toast and the new file is left in its place.  But one of them leaves the old filedate, whereas the other gives it a new filedate.  That doesn't make sense.

As a group moderator, I want to know whether a file in my group's Files is an old file or a new file that I need to look at.  Currently there is no way for me to know that.  I want to be able to look at a file and see that it has a new date indicating that it was newly uploaded.

Andy


 

Why? Because the onlyway to actually update the contents of a file is to reload it. The “entity” that is the file remains the same. If you want a new entity, you upload that and you can delete the current one. It’s very different. 

Without the current distinction, there’s no way to update the content, assuming it’s a pdf file, which are the only kind my group deals with. Maybe there’s another way to update other kinds of files by directly editing them. I wouldn’t know. But preserving this distinction is crucial at least for pdfs, if not others. 


On Feb 19, 2022, at 10:13 AM, Andy <AI.egrps+io@...> wrote:

On Sat, Feb 19, 2022 at 12:38 PM, J_Catlady wrote:
Moving a file no longer counts as an update. That was the whole reason for my OP.  
 
I think that changing the description is correctly categorized as an update, as does replacing the file. Replacing it is the very definition of an “update”. If you want a new “created” date, you would delete the file and upload a separate one. 

In the end, uploading a new version of an existing file is no different from deleting the old one and uploading a new one.  But there are two ways to get there.  One is to manually delete the old file and upload the new file.  The other is just uploading the new file, which replaces the old one with the new one, by internally deleting the old one and uploading the new one, done in one step from the user's point of view.

Why should it matter whether it is done in one step or two steps?  Both accomplish the same thing, which is that the old file is toast and the new file is left in its place.  But one of them leaves the old filedate, whereas the other gives it a new filedate.  That doesn't make sense.

As a group moderator, I want to know whether a file in my group's Files is an old file or a new file that I need to look at.  Currently there is no way for me to know that.  I want to be able to look at a file and see that it has a new date indicating that it was newly uploaded.

Andy

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


Andy
 

On Sat, Feb 19, 2022 at 01:26 PM, J_Catlady wrote:
Why? Because the onlyway to actually update the contents of a file is to reload it. The “entity” that is the file remains the same. If you want a new entity, you upload that and you can delete the current one. It’s very different. 

No, in the end there is no difference.  You end up with the old file gone, and the new file there.  But the new file has a "fake" filedate left over from the old file which is no longer in existence.

Andy


 

Strongly disagree. The perms link link stays the same after file replacement, as opposed to being changed via a new file, “in the end.” The “updated” date reflects actual updating of the content via replacement, but is lost with a new file, “in the end.”

My group’s file on nausea meds for cats was created and uploaded years ago, and it’s contents are being continually updated according to new research, sometimes in a major way, sometimes with just a typo fix. It would be unacceptable to change the “created” date for any change, major or minor.

I think the problem you are having is semantic more than anything else.


On Feb 19, 2022, at 10:30 AM, Andy <AI.egrps+io@...> wrote:

On Sat, Feb 19, 2022 at 01:26 PM, J_Catlady wrote:
Why? Because the onlyway to actually update the contents of a file is to reload it. The “entity” that is the file remains the same. If you want a new entity, you upload that and you can delete the current one. It’s very different. 

No, in the end there is no difference.  You end up with the old file gone, and the new file there.  But the new file has a "fake" filedate left over from the old file which is no longer in existence.

Andy

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


 

typo, permalink


On Feb 19, 2022, at 10:35 AM, J_Catlady via groups.io <j.olivia.catlady@...> wrote:

Strongly disagree. The perms link link stays the same after file replacement, as opposed to being changed via a new file, “in the end.” The “updated” date reflects actual updating of the content via replacement, but is lost with a new file, “in the end.”

My group’s file on nausea meds for cats was created and uploaded years ago, and it’s contents are being continually updated according to new research, sometimes in a major way, sometimes with just a typo fix. It would be unacceptable to change the “created” date for any change, major or minor.

I think the problem you are having is semantic more than anything else.


On Feb 19, 2022, at 10:30 AM, Andy <AI.egrps+io@...> wrote:

On Sat, Feb 19, 2022 at 01:26 PM, J_Catlady wrote:
Why? Because the onlyway to actually update the contents of a file is to reload it. The “entity” that is the file remains the same. If you want a new entity, you upload that and you can delete the current one. It’s very different. 

No, in the end there is no difference.  You end up with the old file gone, and the new file there.  But the new file has a "fake" filedate left over from the old file which is no longer in existence.

Andy

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


 

For most normal situations, if someone uploads a new file with the same name as an existing file, it's intended to be an update. If the file is named favorite_restaurants.txt, for example, and someone uploads a new copy of it, that means they probably discovered a new favorite restaurant and want to update their list. Usually for something completely different, the user chooses a different filename. But if they really want a new created date, the workaround is just to delete the old file first.

JohnF


KWKloeber
 

<<< semantic [s] >>>

There’s many date tags that can be and are associated w/a file.  Which are the important ones for one may differ from another person BUT consider that the last date that one moves a file from one location to another, or for that matter sends a file to another person, does not affect the date the file was created, it was modified (changed and saved back) or it was last accessed (opened but not saved back.)

I edit reports and sometimes give several drafts to clients or associates to review.  The important date is when each file was last modified, not when it was moved from one one of my folders to another.  Or from one person to another — Imagine if that date was “THE date” associated with the file — no one would know which has the most recent content, which is what’s most important to know - not the last time someone looked at the content or moved the contents from a PC to cloud storage for instance. 

Think about this - if you kept reinstalling an application would it be helpful if the ver. # changed each time?  I would think not. What about if one reinstalls the app, how about updating the ver. # then?  No, that info doesn’t change just because it’s moved around or reinstalled and it would be a nightmare if it did. 
Should THE date on an uploaded file change each time someone accesses (say reads) it?  Why not - it is indeed only one of many possible date tags.  ;-)

OR, suppose the date on an email every time it is moved from one folder to another!! One would never be able to locate that email from you boss back in January approving your raise. 

The most important info on an orange juice container is not what day the orange was picked, or hour it was purchased, or moved from the car to the fridge, or moved from the garage to kitchen fridge.  That date also doesn’t change just because the container is accessed. 
    - Created
    - Last modified
    - Uploaded
    - Accessed
    - Re uploaded
all pertain to different key information.


 

I agree with all of this. (But again, moving a file resulting in a new “updated” date is no longer an issue. Mark fixed that. It was the sole point of my OP here.)


On Feb 20, 2022, at 7:48 AM, KWKloeber via groups.io <KWKloeber@...> wrote:

<<< semantic [s] >>>

There’s many date tags that can be and are associated w/a file.  Which are the important ones for one may differ from another person BUT consider that the last date that one moves a file from one location to another, or for that matter sends a file to another person, does not affect the date the file was created, it was modified (changed and saved back) or it was last accessed (opened but not saved back.)

I edit reports and sometimes give several drafts to clients or associates to review.  The important date is when each file was last modified, not when it was moved from one one of my folders to another.  Or from one person to another — Imagine if that date was “THE date” associated with the file — no one would know which has the most recent content, which is what’s most important to know - not the last time someone looked at the content or moved the contents from a PC to cloud storage for instance. 

Think about this - if you kept reinstalling an application would it be helpful if the ver. # changed each time?  I would think not. What about if one reinstalls the app, how about updating the ver. # then?  No, that info doesn’t change just because it’s moved around or reinstalled and it would be a nightmare if it did. 
Should THE date on an uploaded file change each time someone accesses (say reads) it?  Why not - it is indeed only one of many possible date tags.  ;-)

OR, suppose the date on an email every time it is moved from one folder to another!! One would never be able to locate that email from you boss back in January approving your raise. 

The most important info on an orange juice container is not what day the orange was picked, or hour it was purchased, or moved from the car to the fridge, or moved from the garage to kitchen fridge.  That date also doesn’t change just because the container is accessed. 
    - Created
    - Last modified
    - Uploaded
    - Accessed
    - Re uploaded
all pertain to different key information.

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu