Windows owncloud client looking at filename and hidden-attribute to mark files as hidden

the owncloud client on windows is not syncing files which names start with a dot, like .env, .gitignore, .whatever.
because those are “hidden” files.
while they do have not: the attribute ‘hidden’ enabled.
It’s not because Linux wrongfully handles all files starting with a . as hidden files without looking at their attributes, that the windows client should do so as well.
I don’t care on which OS the server is running.
I expect all non-hidden files - those that do not have their attribute ‘hidden’ enable - to be synced if i disable ‘sync hidden files’, and i expect them to show up in on the server without the need to enable ‘show hidden files’, cause they aren’t hidden at the first place.
for example files named ‘.env’, and ‘.gitignore’ do not get synced even if they are not hidden files (attributed ‘hidden’ is not set)
but if i enable “sync hidden files”, thsoe .env and .gitignore files get synced all of the sudden, but folders like ‘.git’ or files like ‘desktop.ini’ - that do have their hidden-attribute set - also get synced. which is unwanted

same on the server: files that have their ‘hidden’-attribute set are not shown, but also files that start with a . are not shown if you don’t enable “show hidden files”.

Expected behaviour

I expect a windows client to only look at the attributes of a file - same as folderoptions in windows does when you choose to show or hide ‘hidden files’. or like command-line command DIR or DIR /A:-H only shows non-hidden files (attribute ‘hidden’ is not set) independing of the filename starting with . or not. and DIR/A:H only shows files with the ‘hidden’-attribute set not caring if the filename starts with . or not.
aka: same as any other windows program does

Actual behaviour

the windows client looks at the attributed ‘hidden’ if this is set or not, and at the filename, whether or not it starts with a . (a dot) and sees both as ‘hidden’ files and doesn’t sync them if “sync hidden files” is not enabled in the settings.

Steps to reproduce

  1. install latest windows owncloud client,

  2. create 4 files in a folder:
    a. “visible.txt” that does not has its ‘hidden’-attribute set,
    b. “hidden.txt” that does has that atttribute set,
    c. “.visible” file that does not has that attribute set
    d. “.hidden” that does has the attribute set

  3. set the client to not sync hidden files and set up a folder sync for the above folder

only the first file gets synced, while both the 1st and the 3rd file should get synced according to their attributes.

  1. set the client to sync hidden files and all 4 get synced.

Server configuration

Operating system: arm64 armbian ubuntu v20

everything alse like in the docker-compose example file as shown in the documentation on the owncloud-site.

Client configuration

Client version: latest windows client 2.11

Operating system: windows

OS language: dutch

Installation path of client: shouldn’t matter - there are no spaces in the installation path and plenty of disk space avail.

Logs

the above should be clear - check steps to reproduce.

either make the client to correctly only look at the attributes of a file to mark a file as hidden or not.
or make an option avail to ignore seeing filenames starting with a dot (’.’) as hidden, but still see files with attribute ‘hidden’ enabled as hidden.
or make 2 options avail:

  1. sync hidden files with attributed ‘hidden’ set (windows style)
  2. sync hidden files which filenames start with . (linux style)
    which can both be switched on or off in any combo.
    (and tbh : do the same on serverside - windows users don’t care about linux idiotic behaviour of hidding all files that start with a . whether they have that hidden-attribute set or not)

and how can i set the current client to correctly sync .files (filenames starting wih a .) but not sync hidden files (attribute ‘hidden’ set)?

You should care, since that attribute doesn’t even exist in most operating systems.

wrong: As a user on the client side, i don’t and shouldn’t care (and shouldn’t even known) what OS the server is running.
I want my files to be reflected like they are existing in my local folder.
For windows files starting with . are not hidden files, so that behaviour also doesn’t exist on all OS’es.

Whether they are or not, they are treated as such by the ownCloud client, and this is explicitly mentioned in the documentation.

This did appear as an issue in Github over five years ago and was responded to and closed the same day.

Maybe someone else will have some other ideas they can share that are more to your liking.

1 Like

Tell me you didn’t read or tried my ‘how to reproduce’-text without saying you didn’t read or tried it.
And that you as a linux-fanboy were just triggered by the “linux.idiotic behaviour” in my post

Also the info in the docs you point to:

Sync hidden files
Hidden files are files starting with a dot like .filename.txt , but not files which are hidden by setting a file attribute.

As i clearly stated in my problem-description:
the windows client is looking at both the filename and the attribute.
owncloudscreenshot
“bestand/map is genegeerd omdat het verborgen is” (dutch) = “file/fodler is ignored because it is hidden” (english)

Yet if you would have tested my example to reproduce the problem, or look at the screenshot above, the windowsclient looks at both the hidden-attribute and at the filename.

All i ask is for a solution that it only looks at the attribute, not at the filename.
or that there is a possibility to make an option in the (windows-)client to look at one (attribute) or the other (filename) or both.(attribute and filename as it does now)
But not this ‘we only look at the filename not the attribute’-theory while looking at both in practice.

I’ll gladly tell you that I skimmed just enough of it to fully understand your issue. I certainly don’t need to “try it” to know that it will behave as designed. I am definitely not affected by this extreme corner case, and my advice is to adapt your naming conventions to a more a compatible syntax. That is precisely why I said:

And i’m telling you again:
it does not behave as designed.
with the windows client:

  1. create 4 files in a folder:
    a. “visible.txt” that does not has its ‘hidden’-attribute set,
    b. “hidden.txt” that does has that atttribute set,
    c. “.visible” file that does not has that attribute set
    d. “.hidden” that does has the attribute set
  2. set the client to not sync hidden files and set up a folder sync for the above folder

I’m expecting that client to sync files a and c (windows style : looking at atttribute: b & d = hidden),
You’re telling me it will sync files a and b (linux style: looking at filename: c & d = hidden)
but it only syncs file a (combostyle: looking at both the filename and the attribute: b, c & d = hidden)

My screenshot from prev. post also proofs that. 'cause both the “hiddenfile.txt”-file, and the “__ pycache __” folder didn’t sync because of being “hidden” (having their hidden-attribute set) and should have sync’d without problem if it behaved like you think it does and how the documentation tells us it should.

So ty for prooving again you don’t understand the issue, that you don’t even have a clue or care about what the issue really is, and that it’s not “behaving as designed”
Next time please don’t react if you’re not going to read the post at all, and just going to image things.

Please remain polite and constructive in discussions and take care of the Community Guidelines.

1 Like

@LinkP is completely right. This behavior is expected, the client works as designed. Our desktop client is a cross-platform software project which is supposed to work the same on all platforms, no matter if desktop or mobile client or server. Therefore, we treat files whose filenames begin with a dot as hidden on all platforms.

We do not synchronize platform-specific filesystem attributes (e.g., Windows’ hidden flag). The server also just uses the filesystem to store the files, and on Linux such file attributes do not exist either. It is relatively easy to ignore files marked as hidden on Windows locally, though, but once they are uploaded, they will be treated as regular files on all other platforms. You may not want to rely on these flags too much.

As @LinkP also showed, this has been discussed in the past (actually, it has been discussed more than once). We do not intend to ever support this.

You boldly claim that the client does not “work as designed”, for instance, although @LinkP’s links clearly show that this is the case. Why do you think you know better what the developers wanted to achieve originally? It’s more that it doesn’t match your expectations. Since your communication is not in line with our community standards, I don’t think you’re interested in me explaining why your expectations or assumptions are unfounded or incorrect, though. In case you are interested, we can discuss about wherever your expectations don’t match the design, but you need to stick to a professional and friendly tone.

4 Likes

did you see my screenshot?
did you read the way to reproduce it ?
have you tried to reproduce it with a windows client and noticed the wrong behaviour?

the windows client isn’t only looking at the filename, it is also looking at the attribute

I’ll tell it again so you can hopefully understand it as well:
with the windows client:

  1. create 4 files in a folder:
    a. “visible.txt” that does not has its ‘hidden’-attribute set,
    b. “hidden.txt” that does has that atttribute set,
    c. “.visible” file that does not has that attribute set
    d. “.hidden” that does has the attribute set
  2. set the client to not sync hidden files and set up a folder sync for the above folder

I’m expecting that client to sync files a and c (windows style : looking at atttribute: b & d = hidden),
You’re expecting it will sync files a and b (linux style: looking at filename: c & d = hidden)
however it only syncs file a (combostyle: looking at both the filename and the attribute and sees b & c & d = hidden)

This is NOT like the documentation tells me it should behave,
and that is NOT like you 2 tell me it should behave.

I’m not pretenting to know better than you or or the other guy,
i’m not pretending to know better than the programmers.
I’m showing with proof that the client does not work like y’all keep telling me it should.

yet you 2 do think to know better than me what the client is really doing while i show you both screenshots and a way to reproduce it that it not behaving like you’re telling me or like the programmers intent it to work.
but neither of you 2 even try to look at that proof or try to reproduce it.

it’s not my expectations not matching the design.
It’s the compiled windows client not matching the design.

that’s why i posed the question if it would be possible that if that client keeps looking at both the filename and the attribute like it is doing now we can get that double option of either look at the attribute or look at the filename or look at both (as it is doing now on the windows client)

i have done the reproduction step for you 2 so hopefully you understand it now
and i marked the proof in a very clear way that the client is NOT working like the documents and you 2 keep telling me.

“bestand/map is genegeerd omdat het verborgen is” (dutch) means
“file/folder is ignored because it’s hidden” (english)
dir /a:h : list files with the attribute hidden set
dir /a:-h : list the files without that attribute hidden set
again:
why is it also ignoring files with only the attribute ‘hidden’ set while it shouldn’t according to the docs and you 2 ?
Why is it ONLY syncing the file “visible.txt” and NOT the file “hidden.txt” if the client is only looking at the filename and not at the attribute ?
clearly the windows client is looking at both the filenames and at the attributes of the files to mark them as hidden or not.

or are you guys going to keep telling me it is not doing that and “working like documented (only looking at filename)” after this much proof ?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.