XYplorer Beta Club

Most Tags and labels are not being displayed. But curiously, some are.

Forgive me if I did something wrong but because I'm new to this specific feature. Recently I decided to switch to "Configuration/Tags/Storage/Relative to tags database." I was using "Absolute paths" for many years without any problems.
- I copied my TAG.dat file from xyplorer\data to E:\subdirectory1\RelativeTAGS.dat.
I created an admin.ini file with [Path] and the appropriate key FileTagDat=e:\subdirectory1\RelativeTAGS.dat under it.
I started up xyplorer, and also monitored the relativeTAGS.dat file in a text editor for changes.
It didn't affect the file at all until I changed a tag, after which it updated the whole database and changed all the tags on the E:\ drive to relative paths which is what I expected.
Note:: also, because I used a subdirectory to store my tagsdatabase, there are many relative tags that start with something like ..\folder.
- After doing all this everything was fine and worked until restarting xyplorer.
- After restarting, MOST of the tags and labels are not displayed properly. But some are.
- At this time I guessed that maybe the files aren't sorted properly or something got messed up and so I did database check on fixed drives, and it removed several orphaned files which I knew I had.
- Then the tags displayed properly. label colors, comment fields, custom fields, all showed up.
- But upon restarting, they were gone again. And doing database check with no orphans fixes it again.

Comments::
- I have about 2000 tags.
- The tags at the very beginning worked. (Maybe just a coincidence)
- Random tags after that worked but not many.
- I noticed that Tag.dat is usually sorted, which it is after changing to "relative to database" except...
- what used to be the E:\xxx set of tags are not consistent with a sort. This might be by design but I'm suspicious because my tags list looks something like this::
c:\files
c:\subdirectory\files
d:\files
d:\subdirectory\files
..\files
..\photos\files.jpg
file1.xls #these files are actually in e:\subdirectory1 which is correct
file2.png
file3.jpg
..\Excel\doc1.xls
..\videos\movie.mkv
f:\files
g:\files
h:\files
etc...
I always believed that your tag.dat file relied heavily on things being sorted properly so I suspect this could cause things to fail. My tags for the e: drive after changing to relative were left in place. Again, I don't know if this is by design or not but I suspect something might be wrong here. All the drive letters tags are sorted properly and the whole file would be sorted properly if the ones that turned into relative tags were reverted to the e:\xxx absolute path.
So after, thinking it through, I guess one of my main questions is, where do relative path entries go in relation to absolute path entries?
Well, that may or may not be the problem causing the tags not to display, it's just a hunch.

The sorting is done on the resolved absolute paths. The relative paths are just used when writing tag.dat, and are immediately resolved when reading tag.dat.

I made some tests here (replicated your setup) but all looks fine.

Could you just pinpoint one sample case where it does not work?
1) Path of tag.dat
2) Path of the file
3) Entry in tag.dat

Sorry for the late reply. Was busy and then it took some time to figure out a reliably buggy case.
Here's the test case::

1) Path of tag.dat ***************************************************************

2) admin.ini ***************************************************************

This is what is inside XyPlorerDebugSharedTAGS.DAT
*************************************************************** ***************************************************************

Notice that sometimes you get a relative path (..\), and sometimes you get e:\.
This was the easiest case I could create. The labels do not appear. If you label another file in this folder, it will appear until you exit and restart, then it won't appear.
Let me know if you need more information.
Using Xyplorer 19.20

Hi photoman

Are you aware that the current version is 19.50.0229?
So even if the problem you describe is still around in this version and can be fixed somehow, this fix would only be applied to a future version and not your 19.20 one.

More Info on the bug::
If I go into settings and do a database check, it says, "Corrected 4 false capitalizations", even though it doesn't seem to change anything. After doing this, the labels appear and work correctly, until you exit. Then restart again, and the same thing happens - the labels do not appear until you do a database check and get "Corrected 4 false capitalizations".

The change it does is in memory

Use
File - Settings Special - Save Tags
afterwards to save the changes to the tag file
It should
1. Reorder your entries
2. Remove any existing "e:" and replace it with ".."
Try to use an upper-case E here, drive letters in XY aren't
lower-case and the tag.dat file expects correct paths and
XY won't treat e: as E: there...

HighEnd,
Let me just start by saying this... YOU are the man! That was an awesome catch.
I've only tested things for a few minutes, but it really looks like that was the problem, especially given the error message about capitalization.
And lowercase e:\ vs E:\ is a tough tough thing to notice.
Great job!

We should probably either have a short 1 sentence note in the documentation reminding people to make it uppercase, or put a fix in the code to make it uppercase when it reads the admin.ini file.

photoman wrote: ↑22 Jan 2019 04:47... or put a fix in the code to make it uppercase when it reads the admin.ini file.

Next beta.

@Don
XY doesn't mark the tag.dat file as unclean when performing any (in this case: necessary) changes in memory so Save Tags doesn't get the necessary star in front of its menu entry. I would change that as well...

Okay!

After some more testing, there is an issue with capitlization of the folder name and file name as well.
My folder is called E:\Whiteboard. The tags everywhere else shows up fine, but if I tag a file in that folder it doesn't appear. In my admin.ini I specified E:\whiteboard\xxx.dat. Notice the lowercase w in whiteboard. That also causes a problem. But when I changed it to E:\Whiteboard\xxx.dat it works fine.
So it's sensitive to capitlization in the entire path. it's easy for windows users to overlook this because FAT32 and NTFS never care about capitalization the way Linux/Unix does.

This should be fixed in v19.50.0236. Did you test that version?

No, i'm still on 19.50.0200.

So, be assured it's fixed.

OK, the capitlization problem has been fixed.
There still seems to be a problem with relative tags that's exhibiting the same behavior of tags not showing up.
My setup has 2 computers::
desktop::
admin.ini
[Paths]
FileTagDat=e:\whiteboard\XyPlorerDebugSharedTAGS.DAT

laptop::
admin.ini
[Paths]
FileTagDat=q:\whiteboard\XyPlorerDebugSharedTAGS.DAT

So, the desktop is where I did most of my tagging and I want to share it with my laptop because there are a lot of folders synched between the 2 computers so the file structure is very similar and having tags show up in both places automatically is what I'm doing. Any change to the tag file gets synched to the other computer. So they are "sharing" the same tag file, but actually through synching.
When I tried to use it on my laptop, I noticed immediately that anything in the q:\whiteboard folder have tags but do not appear on the laptop. On the desktop it works fine. In debugging, i tried adding tags on the laptop side and then restarting. In this case, the new tags appear but the old ones that were created on the desktop do not. Upon reviewing the tag file, I can see that the new tags are added in a different place in the file. My pc has many drives that are not mapped on my laptop. For example there is an f:\ drive on my desktop which also has files tagged on my pc.
The new tags added on the laptop in the \whiteboard folder are stored after all the f:\<files> tags. But the old ones added on the desktop to the \whiteboard folder are added BEFORE the f:\<files> tags. And I believe this might be the problem.
As you can see, on my laptop the \whiteboard folder is on Q: and on the desktop it is E: which is why one adds tags before f:\<files> and the other adds them after f:\<files> in the tags file.
I assume this is the problem when it's reading the tags file and that's why it's not showing up, because it's expecting the tags in one location in the file and not the other.
I'm using the 19.60 build now.