Unable to access resource

[JohnzaV]

Hi,
I am using QLC 4.12.2. I have a workspace on which I have been working for a few weeks. I've never had any problem with opening it, but suddenly when I try to open it, "Unable to access resource" appears in QLC. Also, I am not able to open workspace directly by clicking on it. This happens on both Windows PC and Mac OSX.

Is there any way to rescue the workspace? I have a backup, but it's quite old...

Thanks guys!

[mcallegari]

The file is gone.
It's all zeroed.
I doubt QLC+ caused this.

[JohnzaV]

Thanks for your answer!

[Xementhal]

I have them same problem.

When i used my backup file on party. Open for the first time and fail the second one.

[jlthla]

So ditto the same issue for me.

I'm designing on a Mac, and playing back on a Pi. I've done this before, but for some reason, whey I transfer the file now, I get the "Unable to access resource" error message. Just not sure what the problem is. Back on the Mac, the file I started from, opens up perfectly....



***UPDATE***

So in looking further, even just moving the file to the Pi, and then back the the Mac, gave me the same error message back on the Mac. Doesn't matter how I moved it over the network, something happens and it gets corrupted, and launching it gives the error message. Very Strange. I was able to just put it on the thumb drive and sneaker net it over, and now it seems to be working just fine. Go Figure...

[markzvo]

We just encountered this today on version 4.13.1 on Windows.

QLC+ definitely causes this. A show was playing on the show timeline, then QLC+ crashed. Reopening the file gave us the "Unable to access resource" error.

The file is still the same large size, but it's been completely zeroed/nulled when examined in Notepad++. 4-5 hours of work lost.

[MichelSliepenbeek]

4-5 hours of work lost.

As an experienced user you know you have to create Back Ups on a regular basis. Just restore your latest Back Up.

[markzvo]

We save often - but that doesn't protect us from total file corruption... Last backup was from before the 5 hours of work.

[mcallegari]

I doubt this is caused by QLC+.
Are you saving on a network shared folder or an external USB drive?

[gHoSTINFERNO]

I just hit this issue as well, file is now all zeroes. Two observations:
1) The file still has a "realistic size". Can't say if that's accurate to the number of bytes or not, but at least comparable size to other files I still have (~29 KiB, another one I have that works is ~28KiB).
2) This is using qlc+ on a raspberry pi, similar to others above (iiuc). As such the data is stored on a micro-ssd.

Given the stability of the raspberry pi platform (generally speaking), I wonder if there is some interaction between qlc+ and how raspberry pis are being used. E.g. I can't say for sure if the last time this one was used & shut down, that that shut down was *clean*, vs just turning off the power (I wasn't the one turning it off). Or I wonder if maybe qlc+, when saving over an existing file, first truncates the file & then extends it to the expected size, and only then writes out the contents and that can fail?

Completely shooting in the dark here, it just seems suspicious and I hope the problem can be found. I do backups, but like others said above, I don't make a backup every time I save an edit while working on it.

Thank you for this awesome tool by the way! And let me know if I can provide more information that would be helpful.

[gHoSTINFERNO]

Forgot to mention in my previous post: this is using qlc+ 4.13.1-1 on an RPi 4B.

[gHoSTINFERNO]

I did some more debugging. The file being all zeroes made me suspicious (see comment about truncation / preallocation in earlier post). Indeed this file is currently "preallocated" but unwritten, i.e. the space was allocated for it, but not actually initialized, that least based on my understanding of the flag "unwritten" being printed by filefrag here:

Code: Select all

$ filefrag -ve badfile.qxw 
Filesystem type is: ef53
File size of badfile.qxw is 29672 (8 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..       7:    3087450..   3087457:      8:             last,unwritten,eof
badfile.qxw: 1 extent found

for a "good file" otoh, this flag "unwritten" is of course not present:

Code: Select all

$ filefrag -ve goodfile.qxw 
Filesystem type is: ef53
File size of goodfile.qxw is 27754 (7 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..       6:    2826895..   2826901:      7:             last,eof
goodfile.qxw: 1 extent found

This could indicate that something used e.g. truncate() to force this filesize to this specific size (after first either deleting the previous version or truncate()-ing it to 0B first, or similar). Of course there is a chance that some random corruption flipped that flag on, but it would seem like a pretty big coincidence.

[gHoSTINFERNO]

All this made me wonder if the "real file" was still hiding under those blocks, and yay, it looks like it was (not 100% yet that it's the latest version, but some spot-checks indicate yes).

What I did:

1. Rerun filefrag in "block" mode (defaults to 1KiB blocks), to get the actual physical offsets of the file:

Code: Select all

$ filefrag -vb badfile.qxw 
filefrag: -b needs a blocksize option, assuming 1024-byte blocks.
Filesystem type is: ef53
File size of badfile.qxw is 29672 (32 blocks of 1024 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..      31:   12349800..  12349831:     32:             last,unwritten,eof
badfile.qxw: 1 extent found

2. Use dd to read those blocks directly into a new file (as root). bs is the mentioned 1KiB, iseek is the start of the physical_offset above, count is the length from above, of is the new filename. Note that if the above would show multiple extents, you would need to stitch this together across multiple sequential parts.

Code: Select all

# dd if=/dev/sda2 bs=1024 iseek=12349800 count=32 of=recoveredfile.qxw
32+0 records in
32+0 records out
32768 bytes (33 kB, 32 KiB) copied, 0.000249071 s, 132 MB/s

3. Confirm the file looks .. reasonable. I just compared the first few lines and last few lines to another file, and then searched for some of the names of chasers etc I could recall. At the very end I expected to see some garbage since this command actually reads a bit more than the length of the file (you could adjust the dd command based on the size shown in the filefrag command, assuming that one is correct). I cut off that stuff using 'vim'.

4. Yay!


So this makes me think either qlc+ indeed truncated the file but then hit an error when writing out the contents, leaving the file in the corrupted state, or, it did write it out correctly, but for some reason it wasn't flushed to the file system and so the truncation survived but not the contents. If so maybe an explicit sync() might help? Again, I'm just shooting in the dark here.

I'm guessing I may have lost the last edit on this file, but better than nothing. I hope this helps maybe finding the root of this, or at least helps others recovering their file.

[mcallegari]

Why do you guys insist QLC+ corrupts or truncate your project files?

Do you know how Linux filesystems work? Are you aware of journaling and alike?
Moreover, over the years I always discouraged project editing on the Raspberry Pi, and yet people keep doing it and complaining it's not like the desktop version.

Sorry but I won't help here.

[gHoSTINFERNO]

Hey,

First off, sorry if we got off on a wrong foot here or something - I didn't mean offense, and I obviously appreciate QLC+, like I stated above. For mobility reasons, a raspberry pi seemed like a great option that worked well so far, which is why I also paid for that version.

I did the debugging above with a few intentions:
1) It confirmed that this seems (likely) related to how writes are flushed, which is indeed related to how journaling filesystems work (and are configured), as you stated.
2) If anybody hits the same situation, they might be able to follow the steps above to get their data back too.

So, with (1) I did some digging, and it looks like QLC+ just writes & then closes the file: https://github.com/mcallegari/qlcplus/b ... f.cpp#L405

But on linux/unix operating systems (can't speak for windows) it is always strongly recommended to explicitly fsync such changes for "important files", e.g. this linux documentation says "configuration files", which I'd say this qualifies (search for "When should you fsync?"): https://lwn.net/Articles/457667/

Out of curiosity I also checked what something like VIM does (I /think/ I'm looking at the right code), and sure enough, they have a length comment that sounds oddly familiar:
https://github.com/vim/vim/blob/04cc897 ... te.c#L2190

Note that QFile (from QT), what QLC+ uses intentionally does *not* fsync, leaving that to the client [1], but it looks like before closing it, one can get the file-descriptor via QFileDevice::handle() [2].
So I think on a LINUX/UNIX, the right way would be to (1) write the data via QFile like it does currently (2) QFile::flush() (3) fsync(QFile::handle()) (4) QFile::close()

I can try to send a pull request later, though it would need to be unix-specific via #ifdefs, I'll try to copy your style for this kind of thing when sending it ..

Cheers & thanks again!

[1] https://bugreports.qt.io/browse/QTBUG-8 ... issue-tabs
[2] https://doc.qt.io/qt-6/qfiledevice.html#handle