.schema not writing to LTO_LOGS about ltopers HOT 21 CLOSED

@retokromer if I write one that solves the issue I will 😊

from ltopers.

uh oh. Do they write when LTO_LOGS is set but not when it is unset?

from ltopers.

They write when LTO_LOGS is set. In our case this is to something other than $HOME/Documents
I haven't checked when LTO_LOGS is unset.

But the issue we have is that they do not write to the specified LTO_LOGS directory, but to the default of $HOME/Documents

This is weird because everything else that is supposed to write to LTO_LOGS does write to the correct, set directory. I can't see why .schema files are going rogue.

from ltopers.

@dericed The schema file will only write after the tape is ejected. I tried moving everything in writelto before case "${TAPE_EJECT}" in y|Y) umount "${TAPE_PATH}" ;; *) echo "Done writing but not ejecting ${TAPE_SERIAL}." ;; esac
but the schema file still wont' write until the tape ejects and when it does write still writes to $HOME/Documents and not to the location defined for $LTO_LOGS in mmconfig.
I think the timing of the schema file writing after tape eject and the writing to the wrong location may be connected. I can't figure out how or why.

from ltopers.

@BleakleyMcD, if you could submit a PR, that would be indeed fantastic!

from ltopers.

@BleakleyMcD I’m teaching in Chennai at the moment, and I cannot do it myself. Yet I’m happy to review, if you can do it. Thank you also for opening the issue.

from ltopers.

I guess, this is resolved in #128.

from ltopers.

Actually, I don't think either issue is resolved with #128 , unfortunately. I will check momentarily.

From earlier:

@dericed The schema file will only write after the tape is ejected. I tried moving everything in writelto before case "${TAPE_EJECT}" in y|Y) umount "${TAPE_PATH}" ;; *) echo "Done writing but not ejecting ${TAPE_SERIAL}." ;; esac
but the schema file still wont' write until the tape ejects and when it does write still writes to $HOME/Documents and not to the location defined for $LTO_LOGS in mmconfig.
I think the timing of the schema file writing after tape eject and the writing to the wrong location may be connected. I can't figure out how or why.

from ltopers.

Thank you, @BleakleyMcD, for reporting. I re-opened the issue then.

from ltopers.

Confirming with the latest ltopers that this is still an issue. The .schema file will not write until the tape has been ejected and, when it does, it writes to $HOME/Documents/ rather than the location specified for LTO_INDEX_DIR in mmconfig. I'm unsure if these two issues are directly related or not. Anyone else having the same behavior? I can't see what the issue is in the code.

from ltopers.

Hey @BleakleyMcD, we started looking at it today. Hopefully will have a fix soon.

from ltopers.

Cooool! Thank you! Interested to see what the problem is...

from ltopers.

Hi @BleakleyMcD, I think the issue may stem from the mountlto script, where LTO_LOGS was still assigned "${HOME}/Documents/lto_indexes." (May have been overlooked in this commit: d48143f?)

When I test it with that change (42f0e83), my .schema files get saved in the directory I specify in mmconfig; however, the .schema files do only write upon mounting and ejecting. (Not sure why as the default LTFS sync time is 5 min.)

Let me know if the first part works for you for now at least!

from ltopers.

Grrrreat! Thank you! I will test next week!

from ltopers.

Is this now resolved?

from ltopers.

And is the documentation up-to-date?

from ltopers.

It is working for us at CUNY TV, but hoping it's also working at NMAAHC for @BleakleyMcD?

Thanks for the reminder about documentation. I made a pull request to update the readme (#139) but since I didn't put in the original changes, I'd love other sets of eyes to make sure it's correct.

from ltopers.

Almost!
.schema files are writing to {LTO_LOGS} but not into {LTO_LOGS}/schema directory, which is the defined {SCHEMADIR}

Our .schema files still do not write until after the tape ejects which is kind of annoying but I'm not sure if that is fixable.

Thank you @aeschweik

from ltopers.

Is this still an issue with the last release (or the HEAD) or has it been resolved?

from ltopers.

Should be fixed in #140, thanks @BleakleyMcD for pointing out my typo! Hope it's working on your end?

from ltopers.

This was my impression too. Thank you, @aeschweik, for confirming it!

from ltopers.