XYplorer Beta Club

Wouldn't be better if tags.dat contained (for example) volume serial instead of drive letter in case of portable devices? In this way tags, labels and comments would be really portable.

Benefits:
- XY or tags.dat can be copied from one computer to another. Portable tags remain.
- If you push your flash drive another USB slot, drive letter may change. Tags remain.

I have seen portable tag discussions, but maybe this point of view didn't come up. If I'm wrong, Don, please ignore my topic.

LittleBiG wrote:Benefits:
- If you push your flash drive another USB slot, drive letter may change. Tags remain.

And this also could occur if you have two USB drives plugged in at same time when you normally have only one...your idea makes sense to me.

Portable tags are on my list. They'll surely come.

They have come today.

I appreciate your work on portable tags, but this solution is especially for the another topic, when XY resides on a portable device and somebody wants to tag files specifically on that. It doesn't seem to be helpful in my case, when XYplorer is on a fixed drive and I have a few flash drives with many tagged files.

My idea, storing volume serial or simply the volume name would ensure, that all path in tag.dat would point to exactly the same place. It wouldn't matter any more, to where you would copy XY and tag.dat. So I think this would be the general solution of portability.

+1

And, additionally, as an enhancement to the tagged objects list manager, a special move function could be there, basically enabling a "replace all" old media IDs (serial number or name, whatever would be used) with a new one (possibly defined by hand and/or from the list of available media). Just an idea - I do not use tags heavily, but have a feeling that only this approach would mean a real portable tag solution.

My idea is for instance to be able to tag images for a life long period (tens of years), during which they will be moved several times to larger and larger media.

Agreed. I might add this later.

Borut wrote:And, additionally, as an enhancement to the tagged objects list manager, a special move function could be there, basically enabling a "replace all" old media IDs (serial number or name, whatever would be used) with a new one (possibly defined by hand and/or from the list of available media). Just an idea - I do not use tags heavily, but have a feeling that only this approach would mean a real portable tag solution.

My idea is for instance to be able to tag images for a life long period (tens of years), during which they will be moved several times to larger and larger media.

Note that I also have plans to support local tag.dat files that would be carried together with the media.

admin wrote:Note that I also have plans to support local tag.dat files that would be carried together with the media.

After years of portability and self-containment phylosophy you would start scattering files outside XY folder?

Marco wrote:

admin wrote:Note that I also have plans to support local tag.dat files that would be carried together with the media.

After years of portability and self-containment phylosophy you would start scattering files outside XY folder?

Only when you wish so...

admin wrote:

Marco wrote:

admin wrote:Note that I also have plans to support local tag.dat files that would be carried together with the media.

After years of portability and self-containment phylosophy you would start scattering files outside XY folder?

Only when you wish so...

From my POV, for this function it makes much sense.

PeterH wrote:

admin wrote:

Marco wrote:

admin wrote:Note that I also have plans to support local tag.dat files that would be carried together with the media.

After years of portability and self-containment phylosophy you would start scattering files outside XY folder?

Only when you wish so...

From my POV, for this function it makes much sense.

From my POV: Scattered tag.dat? Like those descript.ions, thumb.dbs and the like? Blah, pfui, no way.

Leave the control by the user: Why not having an optional argument in the XYplorer command line, to specify from where, or which exactly tag.dat should be used with the instance just starting?

Just my 2ct.

If XYplorer finally support both centralized tag.dat or/and de-centralized local tag.dat (in every folder related and having info absolutaly for the current file folder then this software I can say is one of the official computer revolutions. Advantages on safety with tag.dat in every folder are so strong as much as other advantages of centralized database. Both of them will be the absolute winner. I could forget windows explorer for ever.

ps: I steel can't understand why I waited 25 years for tags. I can't imagine how much productivity has been lost for 2,5 decades having no tags.

And now ... "run Europe run" ! (before the whole capital go to China and India of course)

Borut wrote:From my POV: Scattered tag.dat? Like those descript.ions, thumb.dbs and the like? Blah, pfui, no way.

You may be right for drives belonging to one computer.

But having files with tags on a removable drive, and maybe using this on another PC is another situation, I think. You'd might love if the tags are included with the drive?

Same for external drives used for backup: either data related to the backup (i.e. tags) are contained in the backup - or you have to synchronize every drives backup with a backup of XY data...