The ‘Clear Tile Cache’ takes a very long time to do that. Way faster just using windows explorer. Why so long?
The clear tile cache also needs to do a permanent delete.
When a user removes/deletes a module from their vassal usage, that tile cache should also be deleted (as per 1 and 2 above).
As a Vassal module developer my hard drive becomes quickly cluttered with tile caches. Not a problem with hard drives these days you say. True, to an extent. I dislike having lots of the hard drive tied up with obsolete module versions tile cache’s.
For those that do not know, Windoze only see pic for where that cache is.
How can you tell that Windows Explorer is faster? What shows you that it’s finished? How long does it take to empty the Recycle Bin after you’ve deleted the tile cache in Windows Explorer?
Would you elaborate on that? I don’t know what you mean.
We used to do this. It causes TileNotFound exceptions when there are multiple copies of the same module in the Module Manager and one of those is open.
You can always clear the tile cache if you’re finding it’s too large.
Windows explorer takes several minutes to delete the files in the cache. The clear tile cache time is several orders of magnitude more.
When deleting files via explorer those files are ‘sent’ to the recycle bin. If one presses and holds the shift key then pressing the delete key, the deleted files are permanently erased and normally not recoverable (except via some apps that one can use).
OK.
I do a manual clean up from time to time. But, see attached pic, do the folder names have to be so not understandable? Why not use the module’s file name?
Wait, you’re saying it takes more than an hour to run Clear Tile Cache?! Can you give me some actual times so we know concretely what we’re talking about?
I agree, that’s how the Recycle Bin operates on Windows. This is why “deleting” files in Explorer is fast—“deletion” is not really deleting anything, but is instead just a move. Moving a directory (to a new location on the same filesystem) is fast because all that happens is that it has a new parent set on it. Actual deletion is much slower because you can’t delete a nonempty directory—to delete a directory you have to do a depth-first walk of its tree, deleting leaves, until you’ve worked your way back to the original directory and it’s empty.
Yes, they do, because file contents have no necessary connection with filenames.
Consider what happens if you use the module’s file name for the tile cache directory name and you rename the module. Now you have a tile cache which should be usable, but Vassal has no way of finding it, so you have to retile. What if you replace a module which has already been tiled with a different module having the same filename (I’ve done this many times with modules named test.vmod)? Now you have a tile cache which is for a completely different module, but Vassal has no way of knowing that, so you’ll get TileNotFound exceptions.
The tile cache directories are named for the SHA1 hash of some data from inside the module, and thus suffer from neither of these problems.
Disagree. If I want to delete a particular modules tile cache, it is difficult to ascertain which cache to delete with those folder names. File contents having ‘no necessary connection with filenames’ is a misnomer. Yep, I can name a folder bugger and load it with whatever I want. But with Vassal doing its tiling thing, all tiled files are DIRECTLY related to the module being tiled. So how about that!
In essence, you are pontificating that a very small subset of events directs the norm. That you (and I sometimes) do have modules with the same name, but with totally different contents is not a Vassal issue, but rather a developer problem. You should be using test1, test2, etc. That or delete test before the next iteration.
I do not want to get into a further escalation of what I have originally proposed. I just wanted to highlight the FACT that the ‘clear tile cache’ routine SUCKS and should be looked into.
That clearing the tile cache takes more than a minute or so suggests that something is quite wrong. I’d like to hear from anyone else on Windows how long it takes for them (and what size the tile cache is that they’re clearing, as the time elapsed will be proportional to the tile cache size).
Here’s the complete code in Vassal for clearing the tile cache:
FileUtils.forceDelete(tdir);
Yes, it really is just that one line. FileUtils is from Apache commons-io, so 100% of the code being executed isn’t ours.
I’m willing to try an alternative, but I have no means of testing it myself.
I don’t follow what #2 is about. You seem to think this has some relevance to the problem at hand, but it’s eluding me. Would you try explaining?
You are kidding me. There was absolutely no disrespect. Do not take umbrage so easily and without cause.
Joel continued the discussion quite amicably and even got a snapshot up to try. That is good.
For info, the 4 tile caches depicted take 4.42GB with 171,099 files. Windows explorer takes 1min 54sec to permanently delete them.
Explorer takes around 10 minutes to copy the directory to somewhere else so I could experiment.
I’ll do a current vassal official release (3.6.10) delete and the snapshot for comparison.
I think Brent is serious. Calling their approach “asinine” isn’t how I’d go about convincing volunteers to spend their time fixing my problem.
The long-time maintainer of a port of Firefox to the PowerPC architecture wrote a post-mortem of the project when it ended in 2021 containing a section on bug reports which I’d encourage anyone to read. (Search for “Now for the mildly controversial part” in the text; from there to the end is the relevant portion.)
That said, I’m interested to hear what results you get from clearing the same cache with 3.6.10 and the test build, and I have two questions:
I remain unclear about the relevance of “permanent delete”. Would you explain what you meant by that?
Clear Tile Cache was added in 3.2.4, which is from 2013. Why are we first hearing about how slow it is (on Windows) in 2023?
Permanent delete means the FAT (or modern equivalent) for those files are removed. A normal delete, that ‘moves’ the files to the recycle bin, changes the FAT to indicate that the files now reside in that bin. The permanently deleted files are still there until overwritten by new files, etc. As such the permanently deleted files can still be restored by using data recovery software, unless they have been overwritten that is.
I hope that explains the situation.
Vassal 3.6.9 and 3.6.10 take just over 8 mins (okay, I was wrong about the ‘order of magnitude’ as it is actually just over 4 times slower. Just seemed a long while just waiting).
You sure have hit a sweet spot with the snapshot version though Joel - 53 secs. Windoze is a laggard compared to that impressive figure. Well done (applauds).
Also note that the word asinine is applied to the file tile directory naming system. NOT to a person. In all probability that directory naming system stems from a while ago.
I still maintain, that the directory naming system needs to be way more vassal user friendly.
Therefore, before slam dunking someone, examine the actual context of the message. I did NOT impugn any person, I impugned a directory naming system/protocol, one that has maybe existed for a long time (or maybe not, but who am I to know).
Use some logic here.
I’ve merged the change. It will appear in 3.6.11 soon.
It’s from 2013. I’d do it the same way now, for the reasons I gave above.
The tile cache isn’t intended to be a user-serviceable part. If you’re poking around in it, you’re assuming responsibility for understanding how it works yourself. I don’t want to encourage anyone to tinker with it.
There won’t be a tile cache in V4, so this will all be moot.
Here in lies a difference. Your way, with indecipherable folder names for us mere peasants, and something that actually means something to us peasants. How about a compromise? Tile cache directory names can be either based on the actual module’s file name or what the developers prefer to see. All this is based on the differences between what I (and maybe other non vassal software programmers would like to see in their directory naming structure) and what you, the vassal programmers, would like to see. A part of user/developer only preferences. Thoughts?
Tile directory names must continue to work after module file renaming or movement.
A tile directory must not be incorrectly found when a different module has the same filename as the one for which the tile directory was created.
We will receive endless reports of problems if one or both of those constraints are violated.
If you have a proposal which respects these two constraints and someone implements it, I’d be happy to review a PR for that.
Alternatively, if what you want is a way to clear the tile cache for a single module from the Module Manger, there’d need to be a way to check that no Player or Editor is currently using that tile cache. Again, were someone to submit a PR, I’d be happy to review it.
If I save a module with a new name, Vassal does that. Vassal shows that renamed module as another module with the same version status. Vassal will then tile that renamed module when it is opened.
Moving a module to another directory will muck up Vassal, as it expects that module to be where it was. The resultant error message is:
Note, no option to ‘repoint’ Vassal to the new location.
Renaming a module, via explorer or similar, results in the same error message.
Bad management of file naming is a user problem, not a Vassal problem. (2nd dot point) Just do not have different modules using the same file name. To me, that is just asking for trouble(s).
Changing the file name of a particular module to another, totally different game, module triggers the tiling process.
Seems the 2 dot points are well met. Even if they are, to me at least, rather invalid based on what Vassal actually does. Vassal handles these changes quite well from what I have tested (and experienced).
So what does Windoze do when I copy paste a vassal module in the same directory? Say the module’s name is ‘game’. The pasted new module will be called ‘game (2)’. Relevance? Same folder, same contents, different name. Vassal will take as a new module and treat it as a new module and perform the tiling for that ‘new’ module.
