Announcement

Collapse
No announcement yet.

Webdav, MacOS and silly file names

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Webdav, MacOS and silly file names

    I'm accessing my OX webdav infostore via MacOSX. It works, but I create those typical .DS_Store Files on the server volume. No problem with their existence but they should be ommitted in the infostore listing of the browser frontend.
    Is there perhaps some configure property which hides all those filenames with a leading dot?

  • #2
    Hiding files in a storage is not very clever, just imagine somebody creates 10gig file and sets a dot... how to remove it
    In my opinion, hiding something is the client's job, not the servers one.

    Greetings.

    Comment


    • #3
      Originally posted by Martin Braun View Post
      Hiding files in a storage is not very clever, just imagine somebody creates 10gig file and sets a dot... how to remove it
      In my opinion, hiding something is the client's job, not the servers one.
      I was referring to the behavior of the ls command which hides thos dot filenames by default but can show them by special request. And I'm not so shure who would be the client in this special case. The Mac as a client creates those files to emulate the extended properties for filesystems out of his reach. I still like the idea of simply hiding those files in the webview but display them using webdav. Perhaps I will try myself as the code waits for my enhancements.

      Comment


      • #4
        Ah well, LS is a "client" either, the real file is read from the Disk to the Filesystem to the VFS to the client (at least for linux systems).
        In this case, the Mac is guilty as he creates unnecessary files (.DS is not part of the WebDAV spec) and the server just delivers them as it is his job
        This issue should also apply with the windows .ThumbsDB files iirc. Is there no way to configure the client to not put any waste to the mounted device?
        Last edited by Martin Heiland; 08-08-2007, 08:05 PM.

        Comment

        Working...
        X