Toggle to hide/show hidden files

vincentqb commented 11 years ago

EDIT by @jancborchardt

Solution: We have a settings area in the Files app now so that’s perfect for putting a setting checkbox called »Show hidden files«. Which would be disabled by default. The setting should be persistent across sessions, if changed.

Don’t bother reading the comment thread.

gpaumier commented 11 years ago

If this is only about pictures and thumbnails, the issue should be filed in the apps repo: https://github.com/owncloud/apps , but the question of how to handle hidden files isn't specific to that app: i.e.: should the ownCloud server identify unix hidden files & folders, mask them from view and exclude them from showing in apps, search, etc.

vincentqb commented 11 years ago

Good observations. This discussion is also not specific to unix either, but also applies to other file properties in other OS, like Windows, say. I will post the issue in apps in the meanwhile.

gpaumier commented 11 years ago

I've renamed this issue to broaden its scope to the general handling of hidden files.

jancborchardt commented 11 years ago

This is an interesting question I also pondered. In general I’m a bit hesitant about adding any additional options or toggles in the ownCloud interface, especially for nerdy stuff like this. So let’s analyze 2 possible defaults:

show hidden files: we currently do this, I think. Which are hidden files/folders which are shown but should not? I think there’s a blacklist for stuff like .git and such? What value brings showing hidden files at all?
hide hidden files: the default of any operating system. Some have a toggle to show the files.

I think hidden files should be hidden in the Files app and there should be no option to show them. What are arguments against it?

VicDeo commented 11 years ago

@jancborchardt most obvious is Windows. It has a dedicated attribute to hide the files which is uncommon with *nix systems

blizzz commented 11 years ago

@jancborchardt I have two or three .hidden folders where I put stuff that are use very rarely, like scripts or configs. I don't want to see them usually, only once every 3 months or so. They just take vertical space, a toggle to show/hide them would be awesome. I am fine if it is only a shortcut (like Alt+. as in KDE).

jancborchardt commented 11 years ago

@blizzz oh nice, good point with only exposing it via typical keyboard shortcut!

So, what do y’all say – default to hide hidden files?

vincentqb commented 11 years ago

@jancborchardt This solution would indeed resolve my initial issue.

nuocu commented 11 years ago

JQuery could help out. Basically this scripts checks the event fired by a keystroke. If the keystroke was alt +, it loops over all files and checks if the name starts with a dot. If so, .toggle() is invoked, toggling visibility of this element in the filelist.

$(document).ready(function()
{
    $(window).keydown(function(event) { 
        //+ fires event 107
        if (event.altKey && event.which === 107) {
            //get all the table rows with files and loop (each)
            $('#fileList [data-file^="."]').each(function(){
                $(this).toggle();
            });
        } 

    });

});

is this an idea?

blizzz commented 11 years ago

pull request? :)

erambour commented 11 years ago

I would like to use OwnCloud to remote access and share files located on a Linux server.

These files are mostly read/writen by osx machines, so there's .xxx files everywhere, and these files are usefull for our osx machines (usage of folder colors etc...)

These files are of no interest in Windows/Nix and Web Browsers, so they should be hidden on them.

I have a profond respect for people bringing the community such a great peace of software, but I really don't understand the logic in forced showing the hidden files. If hidden files are possible in most operating systems, and often a useful feature, why not letting users the ability to respect this ?

I would very much appreciate an admin flag or some respect_hidden_files = "true" option in config file to do this. I would have tried to do this myself, but as a new-bee in OC, it's rather hard.

May anyone help / guide ?

Best regards

tanghus commented 11 years ago

but I really don't understand the logic in forced showing the hidden files. If hidden files are possible in most operating systems, and often a useful feature, why not letting users the ability to respect this ?

There's no force involved. A sensible pull request from someone with the time/ability/interest in doing it would suffice.

but as a new-bee in OC, it's rather hard.

Everyone involved in oC was a n00b when we started :)

jancborchardt commented 11 years ago

@erambour please read the discussion before your post. We decided to not show hidden files by default in the web interface (of course they would still be there and synced). And there should not be an admin switch to decide if they are shown or not.

Now the only problem is that someone needs to implement that. So @erambour can you do it?

erambour commented 11 years ago

@jancborchardt, Sorry it was not so clear to me in the above messages that a decision was taken (maybe 'im not fluent enough in english) but i' glad to read this.

Unfortunately, my skills in programming where rather good ... in the time where cpu's where 8bit's, i tried to look a the code (i know a little php) but feel rather lost :-)

I'm not the guy who will do that :-(

jancborchardt commented 11 years ago

Can we please have someone just implement this? Do not show hidden files, simple as that. We don’t even need the shortcut to show them for the first iteration. Currently ownCloud is probably the only file manager which shows hidden files by default.

Calling in @Kondou-ger @kabum because I know you can do that. :)

blizzz commented 11 years ago

Can we please have someone just implement this? Do not show hidden files, simple as that. We don’t even need the shortcut to show them for the first iteration.

That would be a regression for me and break how I deal with my ownCloud. Shortcut is a must for this imho, only then it is an improvement.

jancborchardt commented 11 years ago

Closing this because of the good points regarding platform-incompatibility discussed in #4369.

jancborchardt commented 11 years ago

Ok … so we should not say this is a client issue, because there can be several clients. Can we just have a simple blacklist of files which should be hidden? .DS and ._.DS files as well as Thumbs.db come to mind. That would probably take care of 90% of these problems.

cc @zinkdifferent

DeepDiver1975 commented 11 years ago

Can we just have a simple blacklist of files which should be hidden?

Ok - these file got uploaded and I cannot see them. How can I remove them?

AFAIK mac os is duplicating the files in the .DS - right? There is some impact on quota as well.

Niduroki commented 11 years ago

blacklist Thumbs.db

I better get working on my Thumbnail library, that stores stuff in a DB :wink:

IMO these files shouldn't be uploaded by a client, except especially told to do so.

ZinkDifferent commented 11 years ago

On Aug 30, 2013, at 5:46 AM, Christopher notifications@github.com wrote:

IMO these files shouldn't be uploaded by the client, except especially told to do so.

Please read up on how the platform handles these kind of files. This isn't optional for Mac Finder desktop clients.

ZinkDifferent commented 11 years ago

a) the point has been made that OC is the only filemanager that defaults to showing files that are intended to be hidden. This has apparently been an arbitrary decision, for what I suspect to be ideological reasons. b) a simple configuration toggle would alleviate this problem for everyone. Heck, default it to "show invisible files"

As for the concerns by various participants in this thread:

@DeepDiver1975 : "Ok - these file got uploaded and I cannot see them. How can I remove them?"

The Mac file system will take care of removing them, when/if they are removed via the same WebDAV avenue. caveat: If the main file is removed via the web-interface, the dot-associated files wouldn't be removed. A subroutine in the 'file delete' routine could check if there are files with the same file name, preceded by "._" and thus remove them automatically.

Finally, you can always log in with a regular FTP client that supports webDAV, and which allows toggling displaying or not hidden files, and deleting them that way. I just tested it via Transmit (an FTP client) and it works fine. So, removal is a non-issue.

@DeepDiver1975 : " AFAIK mac os is duplicating the files in the .DS - right?"

That is incorrect. .ds_store files only contain desktop configuration information (ie location and state of folders) and in an ideal world should not be removed, just kept invisible. Since they are minimal text files, quota impact is irrelevant.

@Kondou-ger : "IMO these files shouldn't be uploaded by a client, except especially told to do so."

As pointed out, this is not an optional choice for users using a Mac. These files are operating system specific, no different than .htaccess files, or other dot-files used in Unix (which are routinely defaulted to invisible by all other file managers)

Please, I beg those who are capable of instituting these changes, to at least consider my arguments. Essentially, without this small change, the ability to connect via WebDAV directly from the Mac's Finder is, essentially, worthless.

With this feature, OC would be an awesome client for the Mac platform.

ZinkDifferent commented 11 years ago

Alternatively, could this be provided via an app or 3rd party app? (ie would Owncloud architecture allow this functionality to be provided that way?)

Niduroki commented 11 years ago

@ZinkDifferent

Closing this because of the good points regarding platform-incompatibility discussed in #4369.

How to find out whether a file is uploaded from a windows client or not? And how to find out whether a file is invisible in windows or not? And what, if a windows user has a file like ._..txt, and it's suddenly gone, or "displayed weirdly" (blurred, or something, signalling hidden-ness).

ZinkDifferent commented 11 years ago

Kovdou-Ger,

Why is that every single other file manager or file display algorithm in the world has managed to address this, but it appears to be a problem with Owncloud only?

You do not need to ascertain if a file is uploaded from Windows (though it's obvious from the attributes), this only concerns files of format '.ds' generated by the Mac file system to store state specific information, and files that start with '._'

Technically, the issue of other Unix based invisible files is quite irrelevant - they are invisible on the client end, so won't be manually copied by a unix user, even if they manually mount the WebDAV mount. If they do manually make the files starting with '.' visible in order to copy them over, then they want to copy them, and see them.

Repeat: this is NOT about any and every file that starts with '.' (period), it is only about the two types of files generated on servers by the Mac platform's filesystem.

DSs files - denoting state information ._FileName files, representing the resource fork of files

Windows or Unix users should not see them anyways, if they are present - in fact seeing these files is consistent complaint from Windows users connecting to certain Mac compatible file servers in the past (this has all been resolved years ago by other servers).

Hence, the platform incompatibilities discussed in 4369 are academic and incorrect issue by those completely unfamiliar with the platforms discussed - which is why I am trying to explain this, as it's obvious that no one responding has ever seen or actually used a Mac in file,serving environment.

I'm trying to help, but it appears there is a consistent rejection of this because it deals with the Mac - I'm getting that impression.

ZinkDifferent commented 11 years ago

Repeat: this is NOT about any and every file that starts with '.' (period), it is only about the two types of files generated on servers by the Mac platform's filesystem.

.DS files - denoting state information ._FileName files, representing the resource fork of files

Also, having a cron task delete these files every 5 minutes is NOT a solution, as the .DS files actually contain file system specific data, and they will keep getting recreated every 30 seconds by the file system if not present, or very time another file is being copied.

Niduroki commented 11 years ago

And what, if a windows user has a file like ._..txt, and it's suddenly gone, or "displayed weirdly" (blurred, or something signalling hidden-ness).

I'm sort of saying to do hiding of files properly and fully, or don't. Hiding only some specific files isn't one of these options.

The problem regarding hidden files is platform independence and windows not supplying any attribute regarding hidden-ness over the web. Most people use windows though, so we can't find out in most cases whether a file should be hidden, or not. Unix' hidden 'attribute' being a . at the beginning of the file is a bit weird as well, because a file can't start with a . then.

Doesn't blacklisting .DS… and ._… via blacklisted_files not work in your case btw?

ZinkDifferent commented 11 years ago

On Sep 14, 2013, at 5:33 PM, Christopher notifications@github.com wrote:

Doesn't blacklisting .DS… and ._… via blacklisted_files not work in your case btw?

Please explain. Does this just suppress the files being displayed in the web browser interface?

Where do I set this?

Niduroki commented 11 years ago

In the config file. Have a look at the config.sample.php file. It should prevent uploading and displaying that file.

ZinkDifferent commented 11 years ago

On Sep 14, 2013, at 5:51 PM, Christopher notifications@github.com wrote:

In the config file. Have a look at the config.sample.php file. It should prevent uploading and displaying that file

From what I understand, the blacklisted_files parameter would prevent these files from being uploaded at all.

Which is not the goal here. The .DS files do contain state specific information. Sure, the Finder file system can exist without that information, but it will keep trying to recreate the files continuously.

Less of an issue with ._ files! as they mostly serve for legacy support of files with resource forks! hence! there are very few, if any, still around.

... but why not do it the right way?

I've already explained, this ONLY affects Mac file system situations (which, nevertheless, many people use, particularly in the field that Owncloud would be useful) - and it can be fixed by simply suppressing display only in the web interface.

Which doesn't affect Windows users, or Unix users, at all. There are no platform incompatibilities, as discussed in 2589, except purely academically (ie not ever encountered in a real-world environment). Ever.

ZinkDifferent commented 11 years ago

On Sep 14, 2013, at 5:51 PM, Christopher notifications@github.com wrote:

In the config file. Have a look at the config.sample.php file. It should prevent uploading and displaying that file

Furthermore, the blacklist feature only appears to support full file names, not wild cards.

This would work for the .DS files, but not for any of the . files! as those file names reflect the master filename past the . beginning of the name.

... and, for the record, no, it doesn't work. I added the .dsstore and ..ds_store to the blacklist! and now the client locks up (including the web interface) when attempting to upload (OS X WebDAV) or when attempting to delete .ds_store files.

What is the syntax for the blacklisted_files option?

ZinkDifferent commented 11 years ago

Kondou-ger:

With the blacklist directive in the config.php file, things stop working.

When I only add the same as in the sample file:

"blacklisted_files" => array('.htaccess'),

Then, when copying from the Mac filesystem into a webDAV mounted volume, the files copy fine, and:

no .DS_store files get created, or are visible in the web interface

BUT

the usual ._FileName01 ._FileName02 files still get created and appear.

Does the directive accept wildcard format?

ZinkDifferent commented 11 years ago

"blacklisted_files" => array('.htaccess','.DSstore','.*'),

The above doesn't work.

"blacklisted_files" => array('.htaccess','.DS_store'),

This one does work in ONLY removing the .DS_store files, the other files still are being displayed.

Niduroki commented 11 years ago

No, it doesn't support wildcards.

Shouldn't be that hard to implement, if that solves your problem though …

ZinkDifferent commented 11 years ago

On Sep 14, 2013, at 6:27 PM, Christopher notifications@github.com wrote:

Shouldn't be that hard to implement, if that solves your problem though …

Thanks for your attention to this issue.

Yes, it will somehow solve the issue. It would be a band-aid, a hack, insofar that it would simply prevent those files from actually being copied to the server. While it would functionally "kinda" resolve the most pressing issue, it wouldn't be done 'right'.

How about just implementing the same concept, except only affecting the VIEW of the web interface, as part of a config file?

That would be the 'right' way of fixing this, as it affects only the view, and not the underlying files - some of which are used by the client filesystem.

The default would be unchanged, but if an admin adds or supplies the proper config file, it would allow controlling what is seen on the web interface, while not strangulating a file system from uploading native files.

Remember, when the .DS_store files are gone, the Mac will keep trying to recreate them as long as the webDAV volume is mounted, which will create network and filesystem overhead.

If you only suppress the view of those files, none of this overhead is happening.

Thoughts?

Niduroki commented 11 years ago

Yeah … We could also add a blacklisted_files like configuration entry, with a neutral default, that hides – without a way to unhide – specified entries.

Globbing for both blacklisted_files and hidden_files should be implemented as well.

ZinkDifferent commented 11 years ago

This would be great if that can be added. I believe that will easily and effectively address this entire issue (which, if you look across the forum, keeps coming up.). Just make sure they support wildcards ;-)

Like here:

https://forum.owncloud.org/viewtopic.php?t=9723&p=24055

Thank you!

DeepDiver1975 commented 11 years ago

What could help with respect to webdav is this sabredav plugin http://code.google.com/p/sabredav/wiki/TemporaryFileFilter

ZinkDifferent commented 11 years ago

This is interesting - how would I add it to an existing installation of OC 5.0?

On Sep 15, 2013, at 1:09 AM, Thomas Müller notifications@github.com wrote:

What could help with respect to webdav is this sabredav plugin http://code.google.com/p/sabredav/wiki/TemporaryFileFilter

— Reply to this email directly or view it on GitHub.

ZinkDifferent commented 11 years ago

On Sep 15, 2013, at 1:09 AM, Thomas Müller notifications@github.com wrote:

What could help with respect to webdav is this sabredav pluginhttp://code.google.com/p/sabredav/wiki/TemporaryFileFilter

Okay, so I have added:

protected $plugins = array('TemporaryFileFilter');

to the Server.php file in the 3rd Party directory.

Doesn't work, at least the way it is currently implemented:

immediately, all files in mounted webDAV folder on the Mac side disappear.
copying new files over to the Mac mounted volume generates an error "the file is currently in use"
the files show up on the webView, along with the usual .DS and ._ files.

Am I missing something?

DeepDiver1975 commented 11 years ago

protected $plugins = array('TemporaryFileFilter'); to the Server.php file in the 3rd Party directory.

that's the wrong approach add following to apps/files/appinfo/remove.php as first of similar calls: $server->addPlugin(new Sabre_DAV_TemporaryFileFilterPlugin());

Please note that I have not tested this myself and we need to evaluated the impact on the sync clients

ZinkDifferent commented 11 years ago

On Sep 15, 2013, at 2:49 AM, Thomas Müller notifications@github.com wrote:

Please note that I have not tested this myself and we need to evaluated the impact on the sync clients

Thank you Thomas - I will be glad to thoroughly test this, moving along.

Let me try what you suggested:

add following to apps/files/appinfo/remove.php as first of similar calls: $server->addPlugin(new Sabre_DAV_TemporaryFileFilterPlugin());

ZinkDifferent commented 11 years ago

OK:

using just webDAV mounted folder in the Mac Finder, and the web browser client, it all works as desired. You can copy files to the webDAV volume, and they show up in the web client, and none of the .DS or ._ files are being displayed. (of course, those files are now dumped into a temporary directory, and not removed - also not the ideal situation) - still, as a stop-gap fix, this solution works.
alas, it also breaks the sync-clients. My sync-client on the Mac side now displays a red X icon, and declares 'CSync processing step update failed'

So, one problem solved, another problem introduced.

It basically comes back to what was agreed to by and with kondou-ger earlier - implementing a blacklist for files to hide on the web client front-end. Everything else appears to be introducing a ton of additional headaches.

… unless you have a solution to make the sync-client work, with the SabreDAV plugin changes?

DeepDiver1975 commented 11 years ago

As I said we need to analyze tge sync client impact

@dragotin @danimo

Thx

-------- Ursprüngliche Nachricht -------- Von: ZinkDifferent notifications@github.com Datum:
An: owncloud/core core@noreply.github.com Cc: Thomas Müller thomas.mueller@tmit.eu Betreff: Re: [core] Do not show hidden files in the Files app (#2589)

OK:

using just webDAV mounted folder in the Mac Finder, and the web browser client, it all works as desired. You can copy files to the webDAV volume, and they show up in the web client, and none of the .DS or ._ files are being displayed. (of course, those files are now dumped into a temporary directory, and not removed - also not the ideal situation) - still, as a stop-gap fix, this solution works.
alas, it also breaks the sync-clients. My sync-client on the Mac side now displays a red X icon, and declares 'CSync processing step update failed'

So, one problem solved, another problem introduced.

It basically comes back to what was agreed to by and with kondou-ger earlier - implementing a blacklist for files to hide on the web client front-end. Everything else appears to be introducing a ton of additional headaches.

… unless you have a solution to make the sync-client work, with the SabreDAV plugin changes? — Reply to this email directly or view it on GitHub.

ZinkDifferent commented 11 years ago

iPad & iPhone app work fine with the TempFilesFilter plugin active - displaying content, connecting, uploading files.

This appears to just affect the sync clients on the desktop.

ZinkDifferent commented 11 years ago

Understood - I'm just providing feedback at this point.

Also, my setup uses nginx as the web server, as it provides for chunked transfers, which the Mac WebDAV connection employs (otherwise transfers fail anyway - works beautifully with this latest version of nginx, though - just FYI)

__ ceci n'est pas un iPad

On Sep 15, 2013, at 3:24 AM, Thomas Müller notifications@github.com wrote:

As I said we need to analyze tge sync client impact

@dragotin @danimo

Thx

-------- Ursprüngliche Nachricht -------- Von: ZinkDifferent notifications@github.com Datum: An: owncloud/core core@noreply.github.com Cc: Thomas Müller thomas.mueller@tmit.eu Betreff: Re: [core] Do not show hidden files in the Files app (#2589)

OK:

using just webDAV mounted folder in the Mac Finder, and the web browser client, it all works as desired. You can copy files to the webDAV volume, and they show up in the web client, and none of the .DS or ._ files are being displayed. (of course, those files are now dumped into a temporary directory, and not removed - also not the ideal situation) - still, as a stop-gap fix, this solution works.

alas, it also breaks the sync-clients. My sync-client on the Mac side now displays a red X icon, and declares 'CSync processing step update failed'

So, one problem solved, another problem introduced.

It basically comes back to what was agreed to by and with kondou-ger earlier - implementing a blacklist for files to hide on the web client front-end. Everything else appears to be introducing a ton of additional headaches.

… unless you have a solution to make the sync-client work, with the SabreDAV plugin changes? — Reply to this email directly or view it on GitHub. — Reply to this email directly or view it on GitHub.

DeepDiver1975 commented 11 years ago

Understood - I'm just providing feedback at this point.

Awesome! Much appreciated! In case my short answer did sound rude: I'm sorry - actually I just want the attention of the sync client devs on this issue :wink:

ZinkDifferent commented 11 years ago

No worries, I didn't misunderstand - just wanted to clarify that I'm on board to provide as much feedback as possible, seeing as how it appears that I must be the only Mac user around ;-)

I'm on the US west coast, so sometimes there might be a delayed response.

__ ceci n'est pas un iPad

On Sep 15, 2013, at 4:06 AM, Thomas Müller notifications@github.com wrote:

Understood - I'm just providing feedback at this point.

Awesome! Much appreciated! In case my short answer did sound rude: I'm sorry - actually I just want the attention of the sync client devs on this issue

— Reply to this email directly or view it on GitHub.

danimo commented 11 years ago

My thoughts on this:

The client (1.4.0) should work ok if a .ds_store file appears on the server. Since it's marked as a removable ignore, it should also be removed if it is in the way of removing a directory, also on the server. Anything else is a client bug which should be reported against Mirall.
The question whether specific file should be filtered in the webdav client is tricky because we basically have two types of users: Those who really want to be able to sync and transfer hidden files, and those who don't want to be confused. Whatever we decide here: Don't lie to the client (which also uses webdav!). If a file is there, it's there, and the client (other than ignorant users) really needs to know the remote file system layout by heart.

In conclusion, I don't see a simple way to ignore files for webdav mounts.

ZinkDifferent commented 11 years ago

Please don't start this again. Please.

This isn't a philosophical issue, it's functional - and as pointed out earlier, every utility dealing with cross-platform file systems seems to have dealt with this issue successfully, including SabreDAV, which actually has a filter to deal with this.

I have laid out the various scenarios earlier, and it appears that a blacklist for what files NOT TO VIEW in the webclient is the best solution. There is no "lying" go on to any users - these are files these users wouldn't be seeing with any and every other solution available, including the OC sync clients. In fact, the OC WebDAV is the only such file manager where users would end up seeing unexpected results if they are Mac users or exchanging files with Mac users.

__ ceci n'est pas un iPad

On Sep 15, 2013, at 4:28 AM, Daniel Molkentin notifications@github.com wrote:

My thoughts on this:

The client (1.4.0) should work ok if a .ds_store file appears on the server. Since it's marked as a removable ignore, it should also be removed if it is in the way of removing a directory, also on the server. Anything else is a client bug with should be reported against Mirall

The question whether specific file should be filtered in the webdav client is tricky because we basically have two types of users: Those who really want to be able to sync and transfer hidden files, and those who don't want to be confused. Whatever we decide here: Don't lie to the client (which also uses webdav!). If a file is there, it's there, and the client (other than ignorant users) really needs to know the remote file system layout by heart.

In conclusion, I don't see a simple way to ignore files for webdav mounts.

— Reply to this email directly or view it on GitHub.

owncloud / core

Toggle to hide/show hidden files #2589