lstat /path/dir/.stignore: input/output error prevents starting the folder (Failed initial scan of sendonly folder). Its a readonly directory. The marker already set to a file in this folder. I do not need the stignore function for this folder.
Any way to disable .stignore for this folder only?
“input/output error” is something entirely different than “doesn’t exist”. You should investigate why that error is returned. Is the filesystem unhealthy?
Its a FUSE mount point that provides only read access. Everything else (writes) are answered with:
$ LANG=C touch /path/dir/test
touch: cannot touch '/path/dir/test': Input/output error
for the sake of completeness I tested it on a “normal” filesystem:
# mount -o remount,ro /boot
# LANG=C touch /boot/test
touch: cannot touch '/boot/test': Read-only file system
Not sure if the former is behaving compliant.
Is it a good idea to make Syncthing more resilient in such cases and ignore it?
That fuse filesystem is doing the wrong thing. Syncthing is asking if .stignores exists, and it’s answering effectively “no idea, the disk is broken”. I don’t think it would be a good idea to make Syncthing more resilient here. When the disk or filesystem is bad we should stop and let the user fix it, rather than propagating broken state to everyone else.
Sure, you are absolutely right, things should be fixed where the problem is,
but inferring that “the disk is broken” is to coarse-grained :-).
A look into
func loadIgnoreFile and a small test go code outside of Syncthing applied against the mentioned mount point, reveals that the intention to check for the existence of the file (as stated in your comment) is better done when os.Stat comes before os.Open. Its clearly that in a perfect world this FUSE implementation should respond differently/compliant.
On the other side assuming os.Open could be done blindly does not work for this edge scenario. What is go’s idiomatic way (open then stat, or stat then open)? Thanks.
As an existence check, if the intention is to do anything with the file, just Open() is the only good way. I didn’t look at what we do with the stat result or what it’s used for. (Presumably to check the modtime, and then it doesn’t matter much if we do it before or after open.)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.