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

Check for existing files #55

Open
kallisti5 opened this issue Oct 1, 2021 · 3 comments
Open

Check for existing files #55

kallisti5 opened this issue Oct 1, 2021 · 3 comments
Labels
needs investigation Diagnose what's causing the behaviour described performance Strictly performance related possible duplicate This issue or pull request already exists

Comments

@kallisti5
Copy link

I'm playing with this on our big software mirror... running the sync daemon and adding a test file to trigger ipfs-sync I get pages and pages of...

2021/10/01 11:04:42 Error adding file: cp: cannot put node in path /haikuports/master/x86_gcc2/current/packages/neocd_libretro_x86_source-0.5_20210425-1-source.hpkg: directory already has entry by that name
2021/10/01 11:04:42 Adding file from /home/ipfs/haikuports/master/x86_64/current/packages/assimp_debuginfo-5.0.1-1-x86_64.hpkg to /haikuports/master/x86_64/current/packages/assimp_debuginfo-5.0.1-1-x86_64.hpkg ...
2021/10/01 11:04:42 Error adding file: cp: cannot put node in path /haikuports/master/x86_64/current/packages/assimp_debuginfo-5.0.1-1-x86_64.hpkg: directory already has entry by that name
2021/10/01 11:04:42 Adding file from /home/ipfs/haikuports/master/x86_64/current/packages/libreoffice_cs-7.1.0.3-2-any.hpkg to /haikuports/master/x86_64/current/packages/libreoffice_cs-7.1.0.3-2-any.hpkg ...
2021/10/01 11:04:42 Error adding file: cp: cannot put node in path /haikuports/master/x86_64/current/packages/libreoffice_cs-7.1.0.3-2-any.hpkg: directory already has entry by that name

It seems like checking for the existence of a file in MFS would be better than letting the additional fail? (maybe also comparing the size of the file in MFS and the file on disk)

Ideally it would check the CID of the file on disk vs the CID of the file in MFS, but that might not work out well :-)

@TheDiscordian
Copy link
Owner

@kallisti5 is this a duplicate of #45? If so, I'll tag that issue for 0.8.0 release, and try to get 0.8.0 out sooner.

@TheDiscordian TheDiscordian added needs investigation Diagnose what's causing the behaviour described performance Strictly performance related possible duplicate This issue or pull request already exists labels Oct 1, 2021
@TheDiscordian
Copy link
Owner

TheDiscordian commented Oct 1, 2021

Ideally it would check the CID of the file on disk vs the CID of the file in MFS, but that might not work out well :-)

Now I totally can do this, perhaps I should do-away with xxhash, and store CIDs instead. Would enable behaviour like this to be easily thrown in. (I need to think about this more, as xxhash is very fast, and less strict, which allows it to be so fast AFAIK)

@TheDiscordian
Copy link
Owner

Also if you're copying your IPFS db along with ipfs-sync, as long as the paths are identical and you also copied the ipfs-sync db over, it should not be going over all the existing files again. Though #45 still totally needs to be fixed, as it'd be WAY faster to not hit MFS with all those fails.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs investigation Diagnose what's causing the behaviour described performance Strictly performance related possible duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

2 participants