maindavfs2 - Support: sr #108298, Open hidden directories

 
 

sr #108298: Open hidden directories

Submitter:  Matthew <mcasperson>
Submitted:  Tue 07 May 2013 10:42:41 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Wont Do
Privacy:  Public Assigned to:  _71007
Open/Closed:  Closed Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 09 May 2013 08:34:27 AM UTC, comment #1: 

When a file system cotains directory ITEMS/9 but directory ITEMS does not list directory 9 then the file system is inconsistent.

Your WebDAV-server does not conform to the spec. According the spec a PROPFIND /ITEMS with depth 1 MUST list all resources that are a direct member of ITEMS. If it does not list ITEMS/9 then ITEMS/9 does not exist, or the server is broken.

davfs2 does a lot of caching to reduce traffic and to speed up the file system. davfs2 might allow acces to directory ITEMS/9 though it is not listet in directory ITEMS. But how to cache this information? The next PROPFIND will tell that ITEMS/9 does not exist. Or has it been deleted? How to reference cached files contained in ITEMS/9. To make this work would require to redisign davfs2 in a way that meets the needs of one special, not conforming server. This would leed to conflicts with all other servers and is out of question.

What is wrong with path "ITEMS\00000-01000/0000-1000/000-100/0-10/9"?
It is a good idea to avoid huge directories and replace them with an hierarchy of small directories. This is especially true with an inefficient protocol like WebDAV. Longer path names should usually not be a problem.
But I think your system is unnecessary redundant and inconsistent.
ITEMS/00000-01000: what would be the directory for the next range? ITEMS/01000-02000? And where does 01000 belong to?
ITEMS/01000-01999? Then why not ITEMS/00000-00999?

A better structure would be just to name directories by the leading digits that do not change within this directory and it's subdirectories.
The path to directory 00009 (not 9) would be
ITEMS/0/00/000/0000/00009
Another example would be ITEMS/3/32/327/3270/32705 for directory 32705.
Directory ITEMS/3/32 will hold all directories with names starting with 32.
The path will be shorter, without unnecessary redundancy (I use 32 and not 2 because the directory name might appear without the full path), consistent and easy to read.

Why would it be important to access directory ITEMS/3/32/327/3270/32705 by the name ITEMS/32705?

Werner

- <_71007>
Tue 07 May 2013 10:42:41 PM UTC, original submission:  

We have a WebDAV server that provides a virtual file system to a database.

For performance reasons, the browsable (i.e. what is returned by PORPFIND) filesystem is nested with a directory structure where each directory contains no more than 10 subdirectories. We did this because ls not only wants to pull down the info on the current directory, but also on its children. This way browsing any directory will result in 11 calls to the WebDAV server: 1 for the current directory, and then 1 each for the 10 children.

This works well, but leads to a directory paths like ITEMS\00000-01000/0000-1000/000-100/0-10/9 to access ITEM with the ID of 9.

The WebDAV server will also serve up ITEMS\9 directly. Tools like dave (http://www.webdav.org/perldav/) can cd into ITEMS\9.

davfs does not cd in ITEMS/9, and I can only assume it is because ITEMS doesn't list 9 as a child. But we can't list 9 as a child, because this would result in ten thousand other children being listed, which would make the filesystem unusable when mounted and browsed.

Is this just a limitation of Linux file systems, or can davfs be made to enter directories that are not listed in any PROPFIND queries?

Matthew <mcasperson>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by _71007 (Posted a comment)
  • -email is unavailable- added by mcasperson
  • -email is unavailable- added by mcasperson (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-04-22 _71007 Open/ClosedOpen Closed
    2013-05-09 _71007 StatusNone Wont Do
        Assigned toNone _71007
    2013-05-07 mcasperson Carbon-Copy- Added mcasperson

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code