Handling of file names of multiple attached files is confusing

[Eldorado 31]

The following is true for any type of attached files. I will use Excel for my examples...

 

Case 1: Paste ANY.XLS from outside EN two times to a note and rename one of them to NEW.XLS:
 

• Bug: Both copies of the file will get the new name NEW.XLS
• Bug: Name change of the other file will not be seen immediately (ANY.XLS seems to be active...)

 

Case 2: Paste ANY.XLS from outside EN to a note and rename it to NEW.XLS. Then paste ANY.XLS a second time to your note.
 

• Bug: Second copy will get the name of the (renamed) first one (both are seen as NEW.XLS)

 

Case 3 ("combination use case"): Cut&Paste an already attached file ANY.XLS within a note, rename one of them to NEW.XLS. Double-click the renamed file NEW.XLS to edit its content. Exit Excel to save the changed file.
 

• Bug: EN shows the unchanged file ANY.XLS as NEW.XLS (false) when changed file NEW.XLS is re-imported.
• Bug: Both files do have the same content. Original content of ANY.XLS is lost.

[DTLow 5,749]

It seems Evernote is trying to be clever on duplicate attachment files
No matter how many times you paste the attachment, there is only one copy stored in the database,
Even if you duplicate the file, and try to add it with a different name (ANY1, ANY2, ANY3)  the original name is used and only a single spreadsheet file is stored.

Fom the Evernote developers documentation, attachments are identified by a hash checksum;
spreadsheet ANY.XLS becomes 5F3C0D7B-6372-47DB-B854-1FA877A7F917.XLS

The hash attribute contains an MD5 checksum of the corresponding resource's bytes, which is used as an unambiguous identifier that points from the hypertext to one of the note's attached resources. This identifier is used instead of the resource's GUID so that the note and all its resources can be created and copied without needing to replace the identifier in the copied note.

[Eldorado 31]

Yes, of course. It might have been clever in former times when all of us had to save space on disks ;-)

I know about backup systems that calculate checksum of all files (of a disk, a disk array or disk farms). Files with the same checksum are stored on backup media only one time. This is OK (and has many advantages in space and backup time) - for a backup and only for that.

But within an interactive system (like EN), I expect different things (like every iconized attachment) to be different even if it carries the same name. If I attach ANY.XLS and later an other (or even the same) ANY.XLS to a note, I want to have two distinct attachments (with the same name like there are many John Does around our world...)

If they want to be clever and store identical attachments only once (OK - saves space and transfer time), they should be clever enough to handle operations on references to these attachments like a user expects (as different attachments).

[DTLow 5,749]

4 hours ago, Eldorado said:

I expect different things 

If you repost as a feature request, I'll add my vote.

A work-around is to use separate notes for your duplicate attachments.

>>with the same name like there are many John Does around our world...)

Same name is not the issue.  Your problem was trying to change the name of one of the John Doe clones.

[Eldorado 31]

From my point of view the current handling is buggy - I do not want to have this as a new feature.
I know this WAR but do not like it...

I've a couple of notes (marked as "=overview") that contain attached XLS files. Change activities to the XLS files are documented in the note. Here is an example:

From time to time I want to make a backup copy of the attachment before starting bigger changes to it. So I simply copy&paste the attachment to a new line and want to change its name to "staff-180711.xlsx". You see the problem?

All WARs are ugly and time-consuming...