[Ndn-interest] error with build application log

[Junxiao Shi]

Hi Ishita

I had an ndnfs-port deployment in 2015-2016, so I'll answer from user's
perspective.


> I am trying to debug the error I am receiving while downloading files of
> different size on ndnfs. In according to do this, when I try to move files
> of different sizes to the mount directory(/tmp/ndnfs) AND root
> directory(/tmp/dir), I keep coming across following situations:
>
> 1. If I move the new file to mount directory directly, it copies the files
> to both mount and root directory and I can see DEBUG logs of ndnfs_write
> and sign_segment logs on the ndnfs build window.
>

This is just how FUSE works. The files are physically stored in the root
directory, but it can be seen from both locations. Only one copy is stored
on the disk.
You should modify mount directory only, and never directly modify root
directory.


> 2. Sometimes when I try to move a file to mount directory directly, it
> would give me cp: cannot create regular file ‘/tmp/ndnfs/100KB.txt’: No
> such file or directory
>

In my experience, copying with 'cp' on the terminal always works, uploading
via sftp or scp never works.
This may have something to do with how ndnfs-port monitors and reacts to
file changes.


> 3. In situations of 2, if I try to copy to root directory instead, it
> would copy to both mount and root directories, but I can't see DEBUG logs
> of ndnfs_write and sign_segment logs anymore like in 1 anymore. I need the
> logs as I am trying to overcome another anomaly where the last segment of a
> file gets set to 0. So, being able to see the sign_segment logs is
> necessary.
>

You should never modify root directory directly, even when ndnfs is not
running. It causes inconsistency between file system and ndnfs's database
which stores the signatures.

>
> I do not understand why sometimes copying data directly to mount directory
> works and sometimes doesn't. Does Anyone has an possible explanation to all
> of this? It would be great if someone could explain why the application
> works differently in similar situations.
>

Closing words: I wish there's another app that can serve files from
filesystem directly, without relying on FUSE.

Yours, Junxiao

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20170715/3e0dd02f/attachment.html>