(un)expected files

[mcnesium]

all-inkl.com provides installing Nextcloud through their web interface. They add $CONFIG['tempdirectory'] = '/www/htdocs/user/cloud/tmp/'; to config.php and create that directory.

While the update from 10.0.1 to 10.0.2 the updater condemned this directory /tmp as expected files and stopped there. So I commented out the config line and deleted the directory, and then the updater ran the update as expected. Questions arise:

• shouldn't this be named unexpected files?
• wouldn't the tempdirectory configuration item make the directory yet expected and therefore not a show stopper?

[MorrisJobke]

@mcnesium Thanks for the feedback. Let me try to reproduce this and look into this.

[mcnesium]

Still doing it in NC 11:

What about something like this:

$CONFIG['expected_files'] = array( "logs", "tmp" );

[MorrisJobke]

I would rather go for following: Instead of failing hard showing those files to the user and allow the user to approve those files as being okay (on their own risk). This would also fix the issues in #23 for example.

[jannooo]

I am currently stumbling on this issue, too, while updating from 9.0.53 to 10.0.3 with two other paths:

lost+found seems a bigger issue, because after adding it to getExpectedElementsList(), the next step 'Check for write permissions' fails.

[fireba11]

Basically every shared host environment will have the odd extra files in there. For example in an ISPconfig web there is a stats and an error folder. You need to be able to either ignore these extra files, confirm them (as in it gets remembered) or have a config option to tell nextcloud what additional things are expected.

[McLibboc]

Same problem here when trying to update from 11.01 to 11.02.

Any workaround until this is "enhanced"?

[benkeks]

@McLibboc Moving the extra files to some directory outside the nextcloud installation, performing the update, and moving the files back worked for me.

[stratege1401]

8831 was closed because old duplicate ( 12 dec 2016 - 17 march 2018 !! ), but what is planned ?
what about the "own risk button" ?

[ygoe]

I have "fixed" th updater as suggested in my duplicate issue by adding the extra directory into the list. Now it's completely broken and gone. I guess automatic updating isn't possible with Nextcloud. I now have to save the remains, repair the hosting environment and reinstall it newly. On a production system. Nice Friday afternoon.

[MorrisJobke]

I have "fixed" th updater as suggested in my duplicate issue by adding the extra directory into the list.

Just to make sure: we never suggested this because of exactly those problems. There was a reason why we added stuff like this into the updater and "simply adding a button to ignore" has a lot of consequences.

Sorry to hear that this happened on your side :/

[jospoortvliet]

So perhaps the safest 'fix' is to tell people to do what was suggested by @benkeks - #68 (comment)
move the files out of the way, perform the upgrade, move them back. That makes for a relatively simple change to the text of the warning...

[stratege1401]

sometimes, "moving files around" is a no go !!! breaking symlinks for exemple as sometimes you dont keept track of them ...

this issue is like a dog running at is own tail:
#8831 #8952 #163 #3045 #6906 ....... some of them are closed, referring to another closed referring to another closed referring to the first again and so on ...

maybe this check for extra files should simply go away ...

[ygoe]

@jospoortvliet I can tell you what happens when I move the php-fcgi file "out of the way": The web page will not execute and the upgrade cannot take place. This file is an essential part of the hosting environment. And because people tend to delete it, and then the web server fails to restart, the files are marked immutable in the file system. So at least the updater wasn't able to kick itself out of the world. But it also failed to handle this situation and left me alone with an unusable and undefined state.

If the check for extra files can determine what files don't belong to Nextcloud, then these files should not be complained about, but rather excluded from deleting. That's what would help a lot.

[benkeks]

Yeah, my suggestion was really only meant as a workaround for certain situations.

I actually also think that it's an awkward design decision to allow users to install NextCloud instances in folders with extra files, but then prevent them from upgrading such installations. The upgrade procedure is stricter than the setup, where it should rather be the other way around (or at least equal in strictness).

[CapSel]

Problem still exists for me.

[JackRoublard]

Bumping the issue ; IMO installations that do not have the luxury of having Nextcloud installed in a perfectly empty directory are way too common for this to be ignored; even moreso since the code signing feature has been added.

[brainchild0]

Some hosting environments, especially shared hosting environments, insert extra directory items in an application directory, without offering any option to prevent their inclusion.

In a Plesk hosting environment, several items have been observed as added to the root level of the application directory, including .php-ini, .php-version, and .well-known.

I suggest adding support for a site-configurable list of file names that should be ignored by the updater when checking the integrity of the application directory. For usability, the standard installation may populate it with initial items that are commonly found in certain environments.

The feature might be implemented either through a new configuration field, or through a separate file following the design pattern applied in .gitignore.

[kesselb]

This sounds like a great feature, but currently there are no plans to implement it. Therefore, I will close this ticket for now. This does not mean we don't want this feature, but it is not on our list of things to do soon.

[Alseenrodelap]

Still this issue exists.
It's a safety feature that enables a installation in a folder, but prohibits any updates. How is that safe in the long run?
No good thinking here.