Unfortunately there is no bug here, there is simply no way to preserve this information in that case. What happens is this:

@Bastien Montagne (mont29) 's commit fixes "path not found" reports for

bpy.ops.file.report_missing_files()

however I am running into a related issue reporting console warnings if I run

bpy.ops.file.make_paths_relative()

This has always been the case, the 'library' ID is created the first time you link/append something from a given .blend file, and stays around at least for the editing session (should disappear after save/reload, if you only appended data). Nothing wrong here, this is how it is supposed to work.

Keeping the file directory of an appended object is useful to allow re-using already appended data, instead of appending it again.
But I'm not sure if that directory should appear between the items in the "Blender File" outliner.
@Bastien Montagne (mont29), do you know if this is expected?

The Wiggle Bones Addon causes this crash.

This crash does not occur when I've disabled all addons and start in factory settings. Trying to disable addons one at a time

Below is a log from the crash on my machine.

Not sure this would be much useful to be honest, this info is supposed to fully internal currently, and invisible for the user...

Thank you for your answer (and your work in general)!

It's saved in file to allow re-using same data on future append, even across editing sessions.

I can confirm the problem.
The value in id->library_weak_reference->library_filepath of "MECube.001" points to a path that no longer exists.
But I'm not sure if this is a bug. This value seems to be a utility "to allow re-using already appended data in some cases, instead of appending it again".

Lol, there he comes out of nowhere and just fixes things :D

In T93858#1268204, @Raimund Klink (Raimund58) wrote:

Lukas is currently not active. I'm not sure if it is a good idea to assign it to him.

I did actually see this one, I'll have a look :)

If you compress outside of blender, the header is not kept (needs to start with "BLENDER") and this is what fails in a couple of places.

Lukas is currently not active. I'm not sure if it is a good idea to assign it to him.

In T88294#1201223, @Brecht Van Lommel (brecht) wrote:

Have you tried comparing with an older Blender version like 2.83? A version before memory-mapped files were used for reading .blend files.

I know that in some Windows versions, accessing memory-mapped files on a network drive bypasses the cache manager regardless of what you do. If that's still the case, it could make sense to use file streams when we know the file is on a network drive.

EDIT: though I guess compressed files don't use memory-mapped access, so maybe that's not the issue. Still could be worth checking older Blender versions to see if was better at some point.

Have you tried comparing with an older Blender version like 2.83? A version before memory-mapped files were used for reading .blend files.

This would actually make me guess that the changes in this patch won't help you as the difference in that 11 to 34 seconds is fairly close to the difference in file download size. When compressed it is just downloading the entire thing in one go, while when not it is using those memory-mapped files. It was the latter I was worried about the efficiency on slow connections with high latency, but this seems to show that there isn't much to improve there.

Hey, just tested the timing, it helped a bit. I was testing it on a file that was 22 MB uncompressed and then 5 MB compressed. Loading the basic folder took 34 seconds when loading the uncompressed and 11 when compressed. When loading the folder with objects it took 2:12 to load for uncompressed and 1:45 to compressed. So there is a difference, but it is not that significant in sense of usability.

@Ondrej Martinek (MirekDusin) - but the result is the same. When browsing through hierarchy the file is still loading every time.

In T88294#1191270, @Harley Acheson (harley) wrote:

@Ondrej Martinek (MirekDusin) - Still waiting for you to test.

@Ondrej Martinek (MirekDusin) - Still waiting for you to test.

One other thing that you could test that does not require compiling blender or making any changes....

@Ondrej Martinek (MirekDusin) - ....I can check how to build Blender from source.

Hey, sorry for the radio silence. We can help with our art team to test the possible solution. I can check how to build Blender from source.

@Leon Zandman (lzandman) - ...accesses files using random access...a piece at the end, then some middle part, etc.

In T88294#1167924, @Ondrej Martinek (MirekDusin) wrote:

Sorry but you seem to not understand the problem. What you describe is expected but how it actually behave is not expected. We were testing it today and Blender file we were trying to append from with a size of 22 MB froze the app. This should not be happening. If I would download a file that is 22 MB of size to some local storage, it would take seconds, instead Blender is usually taking minutes and that is only if you are lucky and it doesn't freeze the app.

The network connection speed doesn't seem to be the problem here. However, there might be a difference in the way the files are accessed. When you copy a file from a network location using Windows Explorer or the macOS Finder it just treats the file as a large BLOB and reads the files in one or more chunks sequentially.

Just to back up a bit. I'm not doubting that you are seeing this behavior. And not arguing that it is acceptable behavior either; it sounds unbearable. And also not saying that changes aren't possible that could improve things, new approaches could be used, or even that a "blender resource server service" couldn't be created and run on your hosting server.

Sry, I might have not made myself clear when talking about freezing. By freeze I mean the app stops responding and need to be force quit. So basically it is impossible to append remotely anything from a file of not even that significant size. This is the major issue here, not that I need to wait. I understand that there will always be some delay as long as there is no indexing. Even still the waiting is not really proportionate to the speed of my connection. I can easily download file of size around 20 MB within few seconds, even if Blender would download the file every time I move in the file's hierarchy, it shouldn't take minutes.

I do understand the problem. I'm saying that for "Appending" the slow speeds you are experiencing are caused by the download speeds of your clients, which you say is "least 20 Mbps download." That speed sounds like wifi 802.11g. You can get faster with newer wifi. And even faster if you use a wired connection to the router instead. I get download speeds of about 350 Mbps. We would see an almost identical performance while viewing file system folders (not in thumbnail view) but while Appending mine would work 17X better.

Sorry but you seem to not understand the problem. What you describe is expected but how it actually behave is not expected. We were testing it today and Blender file we were trying to append from with a size of 22 MB froze the app. This should not be happening. If I would download a file that is 22 MB of size to some local storage, it would take seconds, instead Blender is usually taking minutes and that is only if you are lucky and it doesn't freeze the app. This is really an issue if you are working with group of people that are not sharing one office with local storage. If Blender should ever get to be used as a professional tool in larger studios, then those things need to be fixed. I am not sure if this is a bug or just limitation of current Blender and should be added as a new feature in the future using some sort of indexing, but this needs to be tackled.

@Ondrej Martinek (MirekDusin) - ....remote drive is...over the internet...the parties connecting to it have at least 20 Mbps download / upload. Browsing through regular files is pretty fast, happen almost instantly, the problem occurs when one is browsing through the blender file hierarchy.

In T88294#1161025, @Harley Acheson (harley) wrote:

Could you provide more information about your setup? A blender file can be "remotely on a network drive" in many different ways. Is your computer and the network drive on the same physical network and single location? Are you connected to it with network cabling or though wifi? How fast of a connection?

You mention that the "only solution right now is to download the file offline". Generally we only talk about files being online or offline when using a cloud-based service (file sharing over the internet). Is that how you share files? Or do you mean just copying the file to a drive that is on your computer?