airdcpp-web / airdcpp-webclient

Communal peer-to-peer file sharing application for file servers/NAS devices
https://airdcpp-web.github.io
171 stars 31 forks source link

Hashing: [Hasher #1] : Error hashing * : No such file or directory #470

Open slrslr opened 1 week ago

slrslr commented 1 week ago

I am seeing these popups:

06:00:24
Hashing: [Hasher #1] : Error hashing /a/b/_c d/e f/_g h/i - 1_j_k_1.l.m.mp4: No such file or directory

when I request a refresh of a shared directory. But why it is looking for that file, i assume that the refresh should mean to remove no longer existing files/folders from share and such event can not be considered an error.

Application version AirDC++w 2.12.1-8-gaa1d x86_64 Web UI version 2.12.0

maksis commented 1 week ago

Is it a file that you have deleted or does the path still exist? How many errors there are?

slrslr commented 1 week ago

That file has been deleted by me like one week ago (likely before establishing this AirDC session)... My AirDC GUI produced 15 of these Hashing: [Hasher #1] : Error hashing filenamehere: No such file or directory messages today. All are around the time i clicked a refresh button on one of the shared folders. Files are from various directories.

I have found that some of the "no such file" files are a symbolic links to a file which has been relocated to a different subfolder of the directory tree that I have refreshed using AirDC. As I have mentioned, "i assume that the refresh should mean to remove no longer existing files/folders from share and such event can not be considered an error".

When i do second refresh of same shared folder, it again spams errors for the same files.

maksis commented 1 week ago

So the issue is that there are outdated symbolic links pointing to non-existing files? That sounds like an error to me.

slrslr commented 1 week ago

No, you have wrongly read. I have written "some of the", not all. And even if all, then it is not error. I have told you 2 times, that the no longer found file (incl. symlink) should be just removed from share, it is logical. Instead of spamming user screen every time a file is removed/moved/not found.

maksis commented 1 week ago

And even if all, then it is not error

No, I don't consider symlinks pointing to removed files to be so normal that the errors shouldn't even be reported.

This also has nothing to do with removing deleted files from share, the hashing error indicates that the application tries to add those files in share because there's something on the disk pointing to them.

If there's a generic issue regarding deleted files that doesn't involve broken symlinks, you should use the bug reporting template and include all the requested information, including the steps to reproduce the issue. I can delete files just fine without any errors.

slrslr commented 1 week ago

Thank you. Then I think that it is working as expected - symbolic links with missing target spams the screen bothering user instead of considering such link as a non existing file and skipping it with a NOTICE or WARNING without SPAMming the screen.