search

xybu / onedrive-d-old

Microsoft OneDrive client on Linux.
http://xybu.me/projects/onedrive-d/
GNU Lesser General Public License v3.0
820 stars 143 forks source link

File in shared folder gets automatically renamed. #127

Open daghendrik opened 9 years ago

daghendrik commented 9 years ago

I cloned and installed the future-deamon version yesterday on my raspberry pi. It all works fine except for shared folders, which has some weird behavior:

When made a folder called "public" shared (to everyone with the link) and uploaded a file to that folder, it first created a duplicate file with the filename followed by "(raspberrypi)", which is the network-name of the pi. Then the original file disappeared and the "Filename (raspberrypi).zip"-duplicate remained. (See screenshot Capture1 and Capture2). This only happened to the file in the shared folder. Other files in private folders are not affected.

capture capture2

sirber commented 9 years ago

I get the same issue with files in standard folders (aka not shared). My files gets dupplicated, the original one and a copy with the machine name in bracket.

ex: test.mp3 test (sirber-usb).mp3

marty90 commented 9 years ago

I had this problem too. I had a set of files like this. archive.zip archive (homme).zip archive (homme) (homme).zip archive (homme) (homme) (homme).zip archive (homme) (homme) (homme) (homme).zip

MHBraun commented 9 years ago

Can confirm this behaviour with machine name (hostname) on Lubuntu 14.04 LTS archive. archive (hostname). archive (hostname) (hostname).* etc up to five duplicates

"*" = any extension

skilleter commented 9 years ago

Confirmed on Xubuntu 15.04

I've synced 131149 files and have 2966 with ' (hostname)' in the name (none, as yet, with multiple duplicates in the name).

I've written a script remove the ' (hostname)' and it will be interesting to see if it starts re-appearing.

Looking at the source code, This may be caused by having remote and local copies of a file which have different timestamp and/or size, which was probably the case for me.

Maybe the issue is also caused by changing the local file when onedrive-d is not running, so it doesn't know whether the remote or local copy has changed and plays safe by keeping both?

xybu commented 9 years ago

I believe there is some inconsistency in the rules how OneDrive server manages shared files. This kind of renaming means the program cannot determine which version, local or remote, is newer at all and has to keep both. For now please add shared dirs to ignore list.

skilleter commented 9 years ago

In my case, none of the affected files are shared, but they are accessed and potentially updated from more then one PC.

sirber commented 9 years ago

same for me, not shared files but synched with many pcs.

xybu commented 9 years ago

@skilleter @sirber That's is one reason why the problem can occur. New OneDrive API might help mitigate the trouble but I am not sure.

skilleter commented 9 years ago

Update - I've just reset the onedrive-d configuration and told it to sync into an empty directory. I still end up with files in there with (homename) in the filename even though onedrive-d is the only thing that's accessing the files in the directory.

sirber commented 9 years ago

I've seen the official onedrive client do that when it cannot safely merge files. The one I had this issue with are Access Databases. Maybe the server think the file is opened (or locked) and cannot overwrite it.

sirber commented 9 years ago

Any update on this (major) issue?

ewann commented 9 years ago

tldr: a possible workaround is presented below; if people experiencing this issue could post the output of: lsb_release -a

It might help to narrow down the impact surface.

I'm not sure if anyone is actively working on this issue at this time. If they are, I'd be interested to discuss further. By coincidence I experienced something similar recently for which I found a workaround. It would be interesting to see what of my experience others can replicate:

System experiencing the issue: lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 15.04 Release: 15.04 Codename: vivid

uname -srvpio Linux 3.19.0-22-generic #22-Ubuntu SMP Tue Jun 16 17:15:15 UTC 2015 x86_64 x86_64 GNU/Linux

(Docker container) system not experiencing the issue: lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 15.04 Release: 15.04 Codename: vivid

uname -srvpio Linux 3.19.0-22-generic #22-Ubuntu SMP Tue Jun 16 17:15:15 UTC 2015 x86_64 x86_64 GNU/Linux

Analysis: in my case, the issue is more nuanced than a "Distro X, release Y, kernel Z" problem. There seems to be something more specific about the set of packages / configuration that, for me at least, causes this issue.

For my system that experiences the issue, I found I'm able to stop / prevent it from happening by removing package ionotify-tools.

Possible (very little external validation) workaround: sudo apt-get remove ionotify-tools

I've commented about this in https://github.com/xybu/onedrive-d/issues/164 & https://github.com/xybu/onedrive-d/issues/155, which are potentially related. https://github.com/xybu/onedrive-d/issues/155 in particular highlights there are potential negative consequences to removing ionotify-tools. It seems possible to mitigate these by further modifying DEEP_SCAN_INTERVAL in config_v2.json.