Soft links

BSzili
2014-03-19
2014-04-06
1 2 > >> (Page 1 of 2)
  • BSzili
    BSzili
    2014-03-19

    I added some debug output to the ReadSoftLinkDopus function. This could help to find out why the soft links aren't resolved properly.

     
  • xenic
    xenic
    2014-03-19

    @BSzili
    I commited links.c with fixes for OS4. My debug output indicates that it works but I will retest to be sure. The links.c-ReadSoftLinkDopus() function returns the type information (file/dir) in a fib structure to buffer.c-create_file_entry() which uses that information to determine how the entry will be displayed. However, the create_file_entry() function doesn't pass the file/dir link information back to function_readdir.c-read_dir() or other calling functions.

    I was planning on adding an element to the DirEntry structure (i.e. link_type) so that the create_file_entry() function can put that information in the DirEntry structure for reference by read_dir() and other functions. I want to be sure you don't have some other plan before I make that change. Is it O.K. with you?

    OS4 link info:
    Os4 automatically resolves links. When you get a Lock() on a link, OS4 DOS actually returns a lock on the file that the link points to. That's why there is no ReadLink() function in OS4.

    OS4 ExamineDir() puts link information in the struct ExamineData which allows you to detect links. We should be using OS4 Dos macros EXD_IS_FILE, EXD_IS_DIRECTORY etc. instead of directly accessing the exdata->Type element but that's a minor issue.

    OS4 ExamineObject() does not put any link information in the struct ExamineData. You can't detect if a file is a link with ExamineObject(). If you need to detect if an individual file is a link, you need to use the new LockTagList() function. You need to have the latest OS4 SDK to use that function.

     
  • BSzili
    BSzili
    2014-03-20

    @xenic
    I didn't use the EXD_* macros so I can use a switch statement instead of a bunch of ifs. Unless the values change in the future breaking all the existing programs, this shouldn't be a problem.

     
  • kas1e
    kas1e
    2014-03-20

    @All
    I didn't follow very closed in last few days, so be warned that i dunno what lately was fixed in terms of softlinks, but i just build now rev946 for os4, and my soft file link from awk to gawk, still shows as directory in the dopus5 lister and not as file, while in dopus5 it shows like a file (which is right). Dunno if it at moment should be like this still, or not, just to make you know

     
    Last edit: kas1e 2014-03-20
  • xenic
    xenic
    2014-03-20

    @BSzili

    I didn't use the EXD_* macros so I can use a switch statement instead of a bunch of ifs.
    No problem. Whatever works.

     
  • xenic
    xenic
    2014-03-20

    @kasle
    I just fixed the link reading in links.c for OS4. BSzili added some debug output there but I'm not seeing the output for broken links so I need to investigate further. On my system Dopus5 is showing broken links (links where the file pointed to doesn't exist) as directories. We still need to find a way to identify broken links and display them in some special way.

     
  • kas1e
    kas1e
    2014-03-20

    @Xenic

    On my system Dopus5 is showing broken links (links where the file pointed to doesn't exist) as directories.

    Yeah, same for me.

    We still need to find a way to identify broken links and display them in some special way.

    As for "special way", i found that dopus4 do it pretty good. I.e. underscore file name with -1 of size. Maybe we even can borrow some code from dopus4 to ?

     
  • xenic
    xenic
    2014-03-20

    @kas1e
    I just commited a small fix for the links.c (rev 947) that adds a linefeed to the debug output. When you open the directory containing the broken link you should now see some debug output in Sashimi or your serial debug output.

    I'll look at the code today and see what needs to be done to display broken links in some unique way.

     
  • kas1e
    kas1e
    2014-03-20

    @Xenic

    Yep, now i have on serial for my "awk" to "gawk" link:

    [links.c:82 ReadSoftLinkDopus] couldn't resolve link awk: object not found

     
  • xenic
    xenic
    2014-03-20

    @kasle
    I added code (rev 948) to get correct filesize for 4GB+ file links and changed the broken links to show as empty file links instead of as directories. I can't set the filesize to -1 like Dopus4 in order to indicate to the listers that the file is a broken link. Dopus5 uses unsigned variables for file sizes (as does AmigaDOS). I'll probably need to find a flag I can set in the DirEntry structure or add another element to that structure. However, it will have to wait for tommorrow.

     
  • kas1e
    kas1e
    2014-03-21

    @Xenic
    Cool ! It is indeed showups now like an empty file. Imho 0 or -1 not so matter , matter that it showups now as file. Through, currently it just showups as "bold" font, while imho underscore one (as in dopus4) looks better.

     
  • kas1e
    kas1e
    2014-03-21

    @Xenic

    Btw, getsize calculation imho also need changes in terms of soft links for files/directories i assume, because even for small directories (so not related to 64bit support) it calculate wrong.

    Bug happens a bit strange (or not?) : i.e. if i go inside of directory where those directory-soft-links present, and calculate them, then, and in dopus4 and in dopus5 all calcualtes fine. See screenshot #1 (see for dir-links: gfxdep, guidep, joydep and machdep: their size correct and the same).

    Then, if i just go UP on one level, and do calculation of that directory which contain those soft links, then size is cleary different. Check screenshot#2 (see top-level directory SRC which contain those dir-soft-links).

     
    Attachments
  • xenic
    xenic
    2014-03-21

    @kas1e
    BSzili told you in the "64-bit math support for large disks" topic that he hasn't worked on Getsizes (getsize) yet. I also reminded you that he said he hasn't worked on that yet. I assume that he'll get to that as soon as he can.

     
  • kas1e
    kas1e
    2014-03-21

    @xenic
    Seems i just didn't get it, or language bariers, or i just somehow can't understand roots. Can someone cleanup it a bit plz, so i no need to guess anymore.

    For me it all looks like this:

    1. BSZili works on 64bit dos support. And he says he didn't touch getsize in terms of 64bit dos support. That clear.

    2. GetSize didn't works normally for soft-file-links/soft-dir-links and small directory : that not related to 64bit dos support, and , even if BSZili didn't touch it, he works on 64bit dos support, and not on the support of soft-links (on which you works lately).

    So, problem with GetSize which i describe not related to 64bit support (so on what BSZili work), but related to soft-file-links and soft-dir-links. And happens on small directories , where 64bit dos support no need it to make it works.

    What i triyng to say, is that even if BSZili will touch getsize, it will only touched in terms of support 4g+ , but problem with soft-links still here , and will be here. As it happens even with small directories, and not related to 64bit dos support.

    What i miss ?

    Why i annoy about it, it just to be sure that we all understand each others, and that there is bug not related to 4gb+ support at all.

     
  • xenic
    xenic
    2014-03-21

    @kas1e
    O.K. When BSzili has completed 64bit dos support, we can check if getsize still appears to be getting the wrong numbers. As far as numbers and sizes, I'm trying to stay out of his way for now. He just committed changes for ftp.module and probably has more updates to do in callback hooks and other places.

    I think I've done all I can do about links for now. I attempted to have broken links displayed as underlined or italics by adding a flag in dirlist.h so that flag could be set in buffer.c and allow functions in lister_show.c to identify broken links and display them in a unique way. However, that's not going to work at this point. Italics display causes the first character in a name to overwrite the left lister border and underline causes an ugly line to be displayed across the entire width of a lister. Maybe someone can identify what needs to be changed in listers to accomodate italics or underlining at a later time. For now, I've added the comment "UNRESOLVED LINK" in the comment for a link entry that is broken. You can compile the latest code and see how your broken "awk" link looks in a lister to see what I've done.

    I think I'm finished with links and need to catch up on personal stuff now. I haven't even had time to install the new Odessey and test it.

     
  • xenic
    xenic
    2014-03-21

    @kas1e
    I just discovered that DOpus5 can't copy directory links. I tested with old Dopus 5.82 and an earlier version of Dopus 5.90 with the same results. Apparently, Dopus5 has never been able to copy links directory unless it's just an OS4 issue. Someone should test directory link copying on classic OS3 hardware, AROS and MOS to see if it's a problem on all platforms.

     
  • xenic
    xenic
    2014-03-28

    @kas1e

    Btw, getsize calculation imho also need changes in terms of soft links for files/directories i assume, because even for small directories (so not related to 64bit support) it calculate wrong.

    O.K. I've been looking at GetSize and it's a confusing issue as far as links are concerned. Before we make any changes we need to decide how Dopus5 is going to count links. Here is how links seems to be working for various programs:

    AmigaDOS List command includes file link sizes in a directory size when you list a directory but does not include directory link (directory links inside the dir) sizes. If you List a directory link then it shows a size for the directory (based on the sizes of files in the "linked to" directory).

    Dopus4 includes file link sizes in the total bytes shown in the status bar. If you perform Getsizes on a directory link in a lister then that size is included in the total bytes shown in the status bar. If you go up one directory level and perform "Getsizes" on the the previous directory, none of the link sizes are included in the size shown beside the directory entry.

    Dopus5 appears to work the same as Dopus4 for links & files shown in a lister. However, when you go up one directory and perform "GetSizes" on the previous directory, the directory link size is included in the size shown beside the directory entry but the file link size is not included.

    Dopus4 doesn't include link sizes when you perform "GetSizes" on a directory.
    Dopus5 includes the directory link sizes but not file link sizes when you perform "GetSizes" on a directory.

    If you find the above confusing, so do I. You need to decide how GetSizes should work before we attempt to change it. Here are the choices:

    Don't include any link sizes when performing GetSizes on a directory. (How Dopus4 works).
    Include file link sizes and directory link sizes when performing GetSizes on a directory.
    Include only file link sizes when when performing GetSizes on a directory.
    Include only directory link sizes when when performing GetSizes on a directory. (How it works now).

     
  • BSzili
    BSzili
    2014-03-29

    @xenic
    Wow, that sure is confusing. Since there seem to be no "correct" behavior, and function_getsizes is pretty convoluted, I'd say leave it as it is for the time being. In later version we could add an option to the Environment settings, where the user can choose the combination he/she likes the best. Another option would be changing it to match what AmigaDOS does.

     
  • xenic
    xenic
    2014-03-29

    @BSzili
    Unfortunately, Dopus5 GetSizes currently follows directory links and gets filesizes but ignores file links. Logically, it should either include all links when calculating sizes or ignore all links. Right now I'm adding a lot of debug statements so I can see where changes could be made. The "Checkfit" function also uses the "GetSizes" code. If kas1e doesn't express an opinion or argument on the subject, I will try to make GetSizes ignore all links and make CheckFit add all links so it will make an accurate estimate if a copy will fit into a distination disk/partition. Either way, it will be somewhat complicated.

     
  • kas1e
    kas1e
    2014-03-30

    @Xenic
    Imho we better do as in dopus4, i.e. : Don't include any link sizes when performing GetSizes on a directory. Imho that is more right, as "link" is not real file, just a link, and from human logic its kind of ok to not count size of the files to which we have links, as they not real files/dirs, but links.

    • as bonus it will be the same as in dopus4.
     
  • xenic
    xenic
    2014-03-30

    O.K. I'll do it that way. I found a single place to control what gets scanned, so should be easy to switch to counting links if we want.

     
  • kas1e
    kas1e
    2014-03-31

    @Xenic
    Btw, dunno if you notice or nope, but since latest commit where you adapt a bit code, our nightly server can't build aos4 version anymore, and error are:

    buffers.c:230: error: 'EX_LockInput' undeclared (first use in this function)
    buffers.c:230: error: (Each undeclared identifier is reported only once
    buffers.c:230: error: for each function it appears in.)
    
     
  • xenic
    xenic
    2014-03-31

    @kas1e
    Apparently, your server compiler for OS4 has not been updated to the latest public OS4 SDK. For now, I'll change the code to use the old definition (which is still defined in the new SDK). However, you should update to the latest SDK since there are some new functions that we may need to use eventually. When you update, just remember to save the old SDK somewhere in case you have problems with the new one.

    I just committed revision 954 which should fix the problem for now.

     
  • xenic
    xenic
    2014-03-31

    @kas1e
    SInce the listers show softlink file sizes and softlink directory sizes (if GetSize has been used to show a directory size) in the status bar, it seems to make more sense to count link sizes with GetSize and in the listers. If we don't do that then a user can perform GetSizes on a directory in one lister then enter the directory in another lister and see 2 different sizes. I'm waiting until BSzili commits the ExamineLock64() code since it may affect changes I'm making in GetSizes.

    I've discovered another link problem in the listers. Softlink sizes are shown but hardlinks show up as empty files or normal directories. I need to examine that problem too. Since hard links only work on FFS partitions and RAM:, you need to create a hard link in RAM: or an FFS partition to see the problem.

     
  • kas1e
    kas1e
    2014-04-01

    @xenic
    Yeah, all builds fine now.

    As for softlinks problems : i just do check dopus4, and it have the same sizes in lister and in the getsize. Probably code was fixed in that terms and in getsize and in lister, so to skip count of soft links (or maybe it was like this done by original authors even?)

    For me to be honest any way are fine : or full skip everywhere, or full count everywhere. And if count links sizes, then count and files and directories, and so to make it same and in lister, and in getsize. Just choice imho what way is more easy and faster to implement. As skip or count both are ok imho.

    We can check how unixes/windowses do it just in case..

     
1 2 > >> (Page 1 of 2)