Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"File content is not available" is figured when TextFile which content contains '/annex/objects' strings. #129

Open
ivis-akaike opened this issue Jul 28, 2022 · 2 comments
Labels

Comments

@ivis-akaike
Copy link

Hi, G-Node/gogs Team.
I'm developer from Japan who fork "G-Node/gogs".

I want to ask you this issue.

Describe the bug

  1. go myRepository page.
  2. click "New File" button.
  3. enter filename(issue.txt) and contents of this text file.
    this text file contetns is "this text contains '/annex/objects' strings".

image

  1. commit this text file.
  2. figured "File content is not available" sentence and i cant see text file's contents.

image

GIN version and commit
Live branch which tags gin-live-2020-10-24

Operating system
Linux ubuntu 5.15.0-41-generic #44~20.04.1-Ubuntu SMP Fri Jun 24 13:27:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Database
postgres

To Reproduce
show you in "Describe the bug" chapter

Expected behavior
can get and see the file contents.

Actual behavior
can't get and see the file contents.

Additional context
I think this contents is treated as Git-Aneexed contents.
when I look source code (internal\tool\file.go), it said.

image

This code treats git-saved text file which contains '/annex/objects' strings as git-Aneex saved file.
Is this code right?

I want to know the reason why this judgementis needed.
What kind of cases require this judgement?

I think git-annex saved file is symlink.
So, It's enough to check symlink or not.

If there are any mistakes in my understanding please let me know.

sincerely yours,
Nozomu Akaike.

@mpsonntag
Copy link
Contributor

This behavior can be treated as a bug; the current implementation is a heuristic to identify annex symlink files, but is not sophisticated enough to handle the test case you describe.

Thank you for the detailed bug report!

@mpsonntag mpsonntag added the bug label Jul 28, 2022
@ivis-akaike
Copy link
Author

Thank you very much for the swift reply.

I hope this bug will be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants