Hazel

Any cautions on using Hazel with files managed by EagleFiler?

Just make sure that you follow the rules regarding moving and renaming files.

Hazel-ish
I see that the rules allow opening and editing files outside of EF. I quote:

You can:
open files using other applications.
edit files using other applications and save your changes (without changing the filename).

In my experience, doing so causes a loss of sync between file and EF’s index, producing a ‘Failure’ on Verifying.

I’ve become scrupulous about opening files managed by EF only via EF. If one deviates from this and gets those Failure notices, how is one to know what produced the failure?

Any suggestions on this or have I misunderstood something?

Thanks

Correct.

To be clear, this doesn’t have anything to do with the index, which is for searching and will be automatically updated. What happens is that modifying the file causes its checksum to be different from what EagleFiler was expecting. EagleFiler cannot tell whether the file contents are different because you edited the file or because it was damaged. (Some people have suggested that it should keep track of which files you open in another program, look at the modification dates, and guess.)

If you edit the file using EagleFiler, it will update the checksum for you. Otherwise, you need to update the checksum manually if you want to use the Verify command.

I see. So this means that one must keep track of which files have been changed outside of EF and then update their checksums. I guess that’s what I thought. Was just hoping there might be an easier way, since rules ‘allow’ this kind of external fiddling.
Thanks.

Or you could do a Verify to let EagleFiler figure out which ones have changed.

Do you have a suggestion for how EagleFiler could make this easier?

I can make probably only a quite lame suggestion, since I just don’t know enough.
If it’s possible for EagleFiler to keep track of which files have been opened by the another program—and if one can assume that files get corrupted only by other means (this is undoubtedly an untenable assumption—?)—then some way of indicating whether a file with a mismatched checksum has been recently opened by that other program might be enough to enable peace of mind in telling EagleFiler to update checksums for those files without worrying. But I have no idea how files become corrupted and I have little doubt that they could become corrupted upon being saved by the program that made them. If this is so, then my lame suggestion will be just that, lame.

On the other hand, given that EagleFiler produces a checksum for a recently saved file that was opened via EagleFiler, what guarantee is there that such a file won’t be both corrupt and identified by EagleFiler as having the right checksum? Do you follow my convoluted question?
Anyway, I’m trying to say that maybe my lame suggestion in the end would be just as reliable as the current situation. But I await your clarification on this point.

I imagine that for me—since before using EagleFiler I never had any idea about whether a file might have become corrupt or not—if EagleFiler told me that the checksum for a given file didn’t match AND that this file had recently been opened by the creating app., I’d probably rest easy. Maybe I shouldn’t?

So I guess my lame suggestion differs from the idea you mentioned (that EagleFiler should ‘guess’) in that it relies upon the user to decide which mismatched checksums to worry about while giving a little more info about whether or not they’ve been opened.

I have no idea whether there’s any merit to any of this. Best I can do at the moment.

To be really sure, you would need to actually look at the file that was saved (i.e. re-open it). However, in the vast majority of cases I think it’s safe to assume that a newly saved file was saved correctly. This is what EagleFiler does for files that it modifies.

Yes, you can probably rest easy.

I think it would be almost as annoying as the current situation if EagleFiler asked you to decide all the time. So my current thought is that it should monitor files that you open externally via EagleFiler and auto-update their checksums if the modification dates are more recent, and possibly other heuristics. (That’s what I meant by “guess.”)

Sounds like an improvement.
Yes, if freshly saved = uncorrupted (let’s stipulate), then why not let EagleFiler automatically update these checksums.
Thanks for your thoughts on this.

I just discovered that I’ve misunderstood something key to how EagleFiler works regarding checksums. I thought that as long as I opened a file via EagleFiler—by which I mean by double-clicking on the item in the Records list—any changes made would be kept track of. Of course this is wrong and upon Verify a failure results. So it seems that only rtf files edited within EagleFiler will preserve correct checksums. For me, this makes checksums of quite limited value.

I thought the problem arose only with files opened via the Finder, which is why I asked about Hazel. Now I realize that my efforts to open documents through the EagleFiler Records list has been entirely pointless.

If I haven’t got this wrong, how do you recommend making best use of the Verify command?

So I think I’m asking either for clarification that I’ve got this all wrong, or for EagleFiler to update checksums on ALL files upon their being saved by their native app. Or a better idea?

I’m just trying to figure out how to get some use out of EagleFiler’s great feature of tracking the checksum…

Thanks

Edit: Well, now that I’ve read the Manual (p.55) I see that I’ve learned the roundabout way that EagleFiler expects either 1) that I update checksums manually whenever I edit a file (outside EagleFiler–but doesn’t this mean nearly all the time, given that only rtf docs can be edited in EagleFiler?) or 2) that I just forget about checksums altogether. Sorry for all the words that produce such little result.

I think this just becomes a feature request (or a request for clarification about why having EagleFiler automatically update all checksums upon files’ being saved is a bad idea).

Thanks again

Right—just RTF(D) and text files edited within EagleFiler. For many people, that covers everything. What kind of files do you typically edit?

I would do a Verify after each external editing session so that it can find the files whose checksums need to be updated.

That’s certainly what I’d like to have happen, but I think it comes down to a tradeoff of convenience vs. safety. EagleFiler could assume that every file with a more recent modification date has been edited by a native app, but is that what you’d want? Maybe this should be an option.

Right—just RTF(D) and text files edited within EagleFiler. For many people, that covers everything. What kind of files do you typically edit?

Usually I edit my rtf files in Bean, for starters; and then: Mellel, Scrivener. Maybe Notebook.

EagleFiler could assume that every file with a more recent modification date has been edited by a native app, but is that what you’d want? Maybe this should be an option.

Seems to me that the convenient thing might also be safe if EagleFiler could on its own perform an update checksum immediately when a file in its list is saved. But if it requires the user to do this, then some time might pass and who knows what might happen, huh?. Could EagleFiler do this on its own? I’m guessing from your use of ‘more recent modification date’ that the answer here is no (?).

EagleFiler could watch all file saves, but it has no way of knowing which files changed because you purposely edited them.

Ah…So corruption can look just like a Save?

I was assuming that saving a file would look different to EagleFiler than whatever it is that produces corrupt files…

Hmm…

I think it’s just me figuring out the basics here.

Seems I’ll have to choose: monitor my work and update checksums manually or just forget about them. (Third choice—having EagleFiler update all changed files—now seems to be senseless if it means losing the distinction between saved files and courrupted files.)

Thanks

EagleFiler can see if a file’s content has changed, and it can see if the modification date has changed. Saving a file will cause both to change.

Most corruption probably happens as the file content changing without the modification date changing.

If EagleFiler notices that the modification date has changed, this could be because you changed the content on purpose, or because you accidentally saved changes to the file, or because rogue software saved changes to the file, or because disk damage caused the modification date to change, or because buggy software changed the modification date (e.g. during a backup), etc.

In most cases, it’s probably safe for EagleFiler to assume that the file is different because you saved it. This is a tradeoff:

  1. With manual checksum updates, you can be sure that if the checksums match the file is OK. But this is more work for you.
  2. With automatic checksum updates like you’re suggesting, it’s much easier for you, and EagleFiler will still detect most corruption, but it won’t be 100%.

Both are reasonable choices, which is why I was saying this should probably be an option.