Seafile Drive client 2.0 is ready for testing!

[Jonathan]

Hi @rdb

Can you find some related log messages in seadrive.log when you open the docx or pptx files?

[Jonathan]

@gauburtin

But retreiving the files was very long.
I’m quite sure we should disconnect from older version (clear cache) before uninstalling it.
Do you confirm that ?

The long time of retrieving files should be caused by inefficient creation of placeholder files. We’ll fix it in the next version.

You don’t need to clear the cache before installing the new client. The old cache won’t be used by 2.0 version.

[rdb]

Here is what I did: I have three office files in a folder ‘SeaDrive2.0’ - one xlsx, one docx, and one pptx.

I first opened the xlsx file, waited for 5 seconds, closed the file. Then I did the same with the docx and pptx files. At the end, it opened and closed the xlsx file once again.

This is the log output:
[03/24/20 20:23:02] Repo ‘SeaDrive2.0’ sync state transition from ‘synchronized’ to ‘committing’.
[03/24/20 20:23:02] [03/24/20 20:23:02] All events are processed for repo 6094e38a-fd7d-4651-ba14-75f0fe2a3575.
Auto lock file SeaDrive2.0/greattable.xlsx
[03/24/20 20:23:02] Repo ‘SeaDrive2.0’ sync state transition from ‘committing’ to ‘synchronized’.
[03/24/20 20:23:09] Repo ‘SeaDrive2.0’ sync state transition from ‘synchronized’ to ‘committing’.
[03/24/20 20:23:09] [03/24/20 20:23:09] All events are processed for repo 6094e38a-fd7d-4651-ba14-75f0fe2a3575.
Auto unlock file SeaDrive2.0/greattable.xlsx
[03/24/20 20:23:09] Repo ‘SeaDrive2.0’ sync state transition from ‘committing’ to ‘synchronized’.
[03/24/20 20:23:18] Repo ‘SeaDrive2.0’ sync state transition from ‘synchronized’ to ‘committing’.
[03/24/20 20:23:18] All events are processed for repo 6094e38a-fd7d-4651-ba14-75f0fe2a3575.
[03/24/20 20:23:18] Auto unlock file SeaDrive2.0/newpowerpoint.pptx
[03/24/20 20:23:18] Repo ‘SeaDrive2.0’ sync state transition from ‘committing’ to ‘synchronized’.
[03/24/20 20:23:24] Repo ‘SeaDrive2.0’ sync state transition from ‘synchronized’ to ‘committing’.
[03/24/20 20:23:24] All events are processed for repo 6094e38a-fd7d-4651-ba14-75f0fe2a3575.
[03/24/20 20:23:24] Repo ‘SeaDrive2.0’ sync state transition from ‘committing’ to ‘synchronized’.
[03/24/20 20:23:28] Repo ‘SeaDrive2.0’ sync state transition from ‘synchronized’ to ‘committing’.
[03/24/20 20:23:28] [03/24/20 20:23:28] All events are processed for repo 6094e38a-fd7d-4651-ba14-75f0fe2a3575.
Auto lock file SeaDrive2.0/greattable.xlsx
[03/24/20 20:23:28] Repo ‘SeaDrive2.0’ sync state transition from ‘committing’ to ‘synchronized’.
[03/24/20 20:23:32] Repo ‘SeaDrive2.0’ sync state transition from ‘synchronized’ to ‘committing’.
[03/24/20 20:23:32] All events are processed for repo 6094e38a-fd7d-4651-ba14-75f0fe2a3575.
[03/24/20 20:23:32] Auto unlock file SeaDrive2.0/greattable.xlsx
[03/24/20 20:23:32] Repo ‘SeaDrive2.0’ sync state transition from ‘committing’ to ‘synchronized’.

What is interesting:
1.) the files unlocking is logged, but not the locking (intentional?)
2. the pptx file gets unlocked, but it was never shown as locked.
3.) the docx file never got unlocked

[adam]

Installed and testing now! One question - will there be an option to change the default data/cache directory as per the 1.0 client? it has been removed from Advanced Settings in the 2.0 client.

[adam]

the same goes for the cache size limit - it has been removed from the 2.0 client?

[Andre]

Something else that struck me. Is it possible to open files that are not yet fully synchronized?

In version 1.x it was possible to open video files and to view them simultaneously while loading the file in the background.

[rdb]

Please have a look in the manual: https://download.seafile.com/published/seafile-user-manual/drive_client/drive_client_2.0_for_windows_10.md#user-content-How%20do%20I%20clean%20the%20cache?

[adam]

i see in the manual where it talks about no cache size limit required, however i can’t see any reference to the ability to manually set the cache folder location – i would like it to be D:\ as i dont have a lot of room available on my C:\

thanks

[adam]

A further note:

I’ve run into an issue once or twice with windows complaining about filenames being too long, due to the default install path. My filepaths are prepended with:

C:\Users\adam\seadrive_root\myservername.com_adam@myemailaddress.com\folder\folder\folder\folder\a filename.docx

Whereas previously it would have just been:

S:\folder\folder\folder\folder\a filename.docx

I’ve applied a regedit fix to enable ‘LongPathsEnabled’ so i’m hoping that will make the error go away.

edit: the regedit fix did not work. still have issues with long filenames.

[Jonathan]

How long is the rest of your file path, except for the C:\Users\adam\seadrive_root\myservername.com_adam@myemailaddress.com part? Perhaps your file path is already very long. But with the old seadrive it’s combined length is not long enough to make Explore complain.

OneDrive uses ‘C:\Users\username\OneDrive’ as the root. It’s shorter than SeaDrive but it doesn’t support multiple accounts. We’ll think about how to save a few more characters from the path for the users.

[Jonathan]

We’ll add back this feature in later releases.

[Jonathan]

@Andre

Is it possible to open files that are not yet fully synchronized?

No. At least not in near future. The system API says that it support such usage. But obviously OneDrive, who uses the same API doesn’t implement such feature. I doubt how stable this behavior is. We’ll test it when we have more time.

[adam]

Thanks Jonathan,

We have a fairly long file path structure for some files (so it’s becoming a little bit of an issue using seadrive 2.0), but has never posed a problem when using S:. The long root path is causing issues. i might have to revert to the old seadrive in the meantime.

A shortened root path would be ideal.

Cheers,
Adam.

[adam]

@Jonathan

We’ll add back this feature in later releases.

Thanks Jonathan, looking forward to it! in the meantime i am going to investigate a workaround at the operating system level (eg spanning disks in windows to extend my C drive).

[Jonathan]

@rdb

Top 2: Manual file locking for other file types
When non-office files get locked manually in Seahub, any edits done locally are not synced for as long as the file is locked. When the file is unlocked, conflict files are produced. So far, so good.

But: The locally edited files never reach a “sync” status. The status remains „sync pending". A reboot did not change it.

How do you reproduce this problem? When a file is locked from the web, the local file will be set to read-only. You should not be able to change its contents. Even though you opened it before the lock status is synced to the client, notepad will still find it read-only and refuse to save to the file.

[Jonathan]

@adam

spanning disks in windows to extend my C drive

Perhaps you don’t have to. There will be no unknown auto caching behavior in the new version. So the cache usage will be more under control.

[gauburtin]

@Jonathan

ow do you reproduce this problem? When a file is locked from the web, the local file will be set to read-only. You should not be able to change its contents. Even though you opened it before the lock status is synced to the client, notepad will still find it read-only and refuse to save to the file.

Hi,

I’m very aware about long file path, as the structure of our libraries can exceed Windows path limits.
Will it be a potential issue while using Seadrive 2.0 (it is not with 1.* versions) ?

[jacky35]

Yeah, there’s a problem with that. A folder with 10 subdirectories, you can test seadrive will no longer be able to read the files inside these subdirectories.
This is very troublesome.

[Jonathan]

@rdb

Strange. We cannot reproduce the issue locally. If you can stably reproduce it, can you turn on debug messages in seadrive.log so that we can see what file system events are detected? You need to set Windows environment variable SEADRIVE_DEBUG to ‘watch’. Then restart seadrive and do the test agian.

[rdb]

Hi Jonathan,

I did more testing regarding file locking (on two separate machines). My conclusion: File locking seems to indeed work reliably - which is great. But the display of the lock status is suboptimal (which I guess was the reason making me see a problem in the first place.)

So the display issue that I see on my two machines is as follows: Windows Explorer does NOT show the lock status when an Office file is opened. It ONLY shows the lock after performing another file transaction (opening/closing/renaming another file) in the same window triggering a refresh of said Explorer windows.

It is easy to reproduce:

1. Create 3-4 office files in one folder
2. Open the first one
3. Open all other files
4. Start closing them, one after another

After step 2, the opened file is not shown as locked. After 3, the file opened first is now shown as locked, the file you just opened is not shown as locked. After 3, all files are locked except for the last file opened .

I went for dinner after 3. and, when I came back, the last file was still not locked. Hence there is not automatic refresh mechanism that updates the lock status.

From a functional point of view, I think it is not a big problem. When opening the file, the file’s “real” lock status matters meaning that a unlocked file shown as locked is opened in read-write. But it is a cosmetic problem and it may make people believe that file locking does not work properly. Is it an important problem? Note sure, but if there is a quick fix (i.e., a automatic refresh every 5 seconds) I would do it!