Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Platform-Specific filenames make heterogeneous teams a nightmare #6083

Open
ccoenen opened this issue Oct 7, 2017 · 8 comments
Open

Platform-Specific filenames make heterogeneous teams a nightmare #6083

ccoenen opened this issue Oct 7, 2017 · 8 comments
Assignees

Comments

@ccoenen
Copy link

ccoenen commented Oct 7, 2017

My problem:
Different OSs have different constraints in their file systems, we can't change that. In teams that are spread across all operating systems, this creates a problem: Alice uploads a file on her MacOS Computer, and Bob on his Windows 10 machine can't download it. This is not a theoretical problem, but a very real one:

My "not synced" tab looks like this, and I hate it. It makes working in a larger group very error prone.

grafik

Most of these have been created on mac os, where more characters seem to be allowed. In a group of ~40 people working on the same files, things like these are bound to happen. There's no way every one remembers to "never put a question mark in there" or something like that. Also as a regular user I might not be able to work around this: The shared file could be a read-only file for me - So I couldn't even rename it. I would have to contact the author to do it for me.

I want an automatic solution. One where I don't have to go chasing the submenus of my syncer on a hunch. One, where I don't pick up the phone to ask my coworker, just to realize that it's a pretty benign oversight.

Here's my wishlist:
a) at the very least, and in the short term: I want to be notified when something has not been synced. And not in a "go look for it" method, but front and center "You're missing this right now".
b) There should be a server-option (it may even default to " (yes, this should perhaps be raised in owncloud server) that limits the author in their choice of filename. I am totally ok with that option defaulting to "everything is allowed", but for teams such as mine, there should at least be the option to disallow problematic file names.
c) The syncer could work around this problem by modifying the file name to conform to the targeted file system. This is perhaps not very easy, as the syncer would have to make sure that this does not conflict with another existing file, and it would also have to track two files that don't have the same name. Still, I believe this would be the best solution for a user.

(this has been reported earlier as part of ticket #5964 - which has been closed unresolved)

@ckamm
Copy link
Contributor

ckamm commented Oct 10, 2017

a) There could be better messaging about "you're missing files because their filenames aren't valid on your filesystem". There would probably need to be a "yeah, I know but I don't care" option (because as you say, there's a good chance that users can't do anything about it).

b) A server side option for common-denominator filenames makes sense to me. It'd be easy to turn on the filename-sanity checks that Windows needs for all platforms and make them visible errors. It's a frequent usecase that a person wants to sync files between their two homogeneous systems - that's why we don't currently impose restrictions there.

c) Probably best. @guruz @ogoffart Do we have previous discussion on this? It seems to me the simplest solution would be a ridiculous escaping mapping like "?" <-> "{@questionmark@}".

@phil-davis
Copy link
Contributor

And from experience I know that some staff love to write long folder name inside folder names, and write an essay as the file name. They push right up to the (old but still applies to a lot of programs) 256-char path+filename limit on Windows. If Windows is the lowest denominator, then existing filenames created on Windows will not need to be escaped. But if the escaping mechanism makes filenames too much longer, then users receiving files from other systems will hit the 256-char limit more easily.

@ckamm
Copy link
Contributor

ckamm commented Oct 11, 2017

@phil-davis Oh, right. That path limit makes long explicit escapes much less likely to work. :/

@moscicki
Copy link
Contributor

@ccoenen: I think the only proper solution to this is some kind of name translation (like Dropbox tries to do).

If you restrict the set of characters your server accepts then you will still have the same problem (error messages) except that it will be at the side of the producer of these files (rather than at the side of consumer of these files). Additional downside for errors at the producer side is that these files will not be uploaded to the server, so not really "safely stored".

In any case I think my original request was closed without a comment but not solved (interesting practice...). Hence I created a new issue for that: #6092

@ccoenen
Copy link
Author

ccoenen commented Oct 11, 2017

Yes, it's not ideal, but in my use case the consumer often has read-only rights. The producer, at least, is in a position to fix something.
(I also don't really undertand why #5964 was closed in the first place.)

@ckamm
Copy link
Contributor

ckamm commented Oct 13, 2017

Meta: #5964 was closed eventually because we couldn't reproduce @moscicki's problem and he didn't clarify. Now with the screenshot in #6092 it's obvious what's going on and we can address the problem. The issue @ccoenen described was different from @moscicki's and has become this issue.

@ccoenen
Copy link
Author

ccoenen commented Oct 27, 2017

I just realized that nextcloud server already does a similar thing in a very diffent place and situation: If you Own a directory called example and somebody shares another directory with you that's also named example, it will show up in your files as example (2).

I realize that sharing involves at least three different database-tables and that it's a very different cause and effect, still, there is a precedence for changing (and keeping track of) a filename unsuitable in a certain situation.

I also stumbled across #5963, which would become redundant if such a file handling as proposed here were implemented.

@hodyroff
Copy link

hodyroff commented Dec 22, 2017

I continue to believe that the only way to do this is to disallow the most common incompatibilities and fix them automatically before uploading. Yes, this does change the file name without user control, but seems the only proper way. Dropbox provides a great list of exceptions and what they do and I continue to look for volunteers to implement this.
@ccoenen we really worry about ownCloud here as the team has decided to fork off with the client and has not contributed in any meaningfull way since the project started. However this behaviour is proper and has been in ownCloud well before the low quality fork. The huge difference is that this name of a share is something any sharee can rename like he wishes without affecting others.
So when we have time we will work through this list, or people bring up really good reasons why it should be otherwise: https://www.dropbox.com/help/syncing-uploads/files-not-syncing
Would appreciate any help here, including testing and opening issues for each one and of course PRs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants