occ instance:import:user overwrites e.g. Photos with Skeleton files during import

[jnweiger]

Seen with data_exporter-0.2.2

• Admin create user carolina
• user carolina logs in
  • and adds a file empty.txt into the Photos folder.
  • and replaces Portugal.jpg with a different file.
  • and removes the other files.

• occ instance:export:user carolina /tmp/cc3

• admin deletes user carolina

• occ instance:importport:user /tmp/cc3/carolina

• User carolina logs in and sees the original skeleton files. Her own Portugal.jpg is lost. BAD

Expected behaviour:

• Skeleton files should not be written after import.

[dpapac]

@jvillafanez needs more investigating to be done, if this behavior is to be expected

[phil-davis]

When the Importer sees that the user does not exist, it creates the user - good. But it does not make the user do a first login. The files, trashbin and share importer code is then run - good. Then when the user logs in the first time, there will be code that copies the skeleton files into place for the user. In this case, that is a problem. Maybe there is some "easy" way in `lib/Importer/MetadataImporter/UserImporter/import() to set whatever flag that indicates that the user has already had the "first login file system setup" done. Because in this case the import command is doing the file system setup. That would help avoid the skeleton being "restored/copied" over the top of the folder-file structure that has already been imported.

[phil-davis]

PR #236 fixes this for me. It seems to be as easy as just setting the last-login-timestamp so that later code does not end up forcing skeleton files into the user's fie system.

[jvillafanez]

As solution I guess it's ok, but I'm not sure if we should update the login timestamp when the user hasn't logged in.

Alternatively, we could adjust the conditions to copy the skeletons files. For example, if the last login timestamp is 0 and the user folder isn't already created, we could trigger the copy of the skeleton folder. However, it seems this isn't easy to check:

• The getUserFolder returns the user's folder, but it doesn't report whether it has been created in the call, or it was already created before.
• Scanning the folder isn't a good option since we don't know what it could be there. There could be thousands of files in the target file, specially if we're importing data, and I don't think we have a quick way to check if there are files in the folder or not.

Unless someone has a better idea, I think we can go with https://github.com/owncloud/data_exporter/pull/236 , but we'll have to document that the user will be logged in the new server when the import finishes.

[phil-davis]

Unless someone has a better idea, I think we can go with #236

We need to signal to core that the user file system is "already set up". I think that the only way core currently knows that is if the last login timestamp has been set. So, without changing core, I don't see how else to do it. And we want the code to work with older oC core releases.

In real life the imported user is probably about to have their password (re)set and login anyway within the next days. So I don't think it really matters that the last login timestamp is being set to the time of the import.

[phil-davis]

but we'll have to document that the user will be logged in the new server when the import finishes.

See doc PR https://github.com/owncloud/docs-server/pull/1052